Version Control
Version Control
SOFTWARE
WHY DO WE NEED A VCS?
VCSs Track File Changes VCSs Tell Us:
Who made the change?
So you know whom to blame
What has changed (added, removed, moved)?
Changes within a file
Addition, removal, or moving of files/directories
Where is the change applied?
Not just which file, but which version or branch
When was the change made?
Timestamp
Why was the change made?
Commit messages
Code is organized within a repository.
Basically, the Five W’s
2
BRIEF HISTORY OF VERSION
CONTROL SOFTWARE
First Generation – Local Only Second Generation (Cont.)
SCCS – 1972 Team Foundation Server – 2005
Only option for a LONG time Microsoft product, proprietary
RCS – 1982 Good Visual Studio integration
For comparison with SCCS, see this 1992 forum link
Third Generation – Decentralized
Second Generation – Centralized BitKeeper – 2000
CVS – 1986 GNU Bazaar – 2005
Basically a front end for RCS Canonical/Ubuntu
SVN – 2000 Mercurial – 2005
Tried to be a successor to CVS Git – 2005
Perforce – 1995
Proprietary, but very popular for a long time
3
GIT – THE STUPID CONTENT
TRACKER
Started by Linus Torvalds – 2005
After the BitKeeper debacle
Non-linear development!
Branching is cheap and easy!!!!
4
TERMINOLOGY
Branch Commit
A history of successive changes to code Set of changes to a repository’s files
A new branch may be created at any time, from More on this later
any existing commit
May represent versions of code Tag
Version 1.x, 2.x, 3.x, etc. Represents a single commit
May Represent small bugfixes/feature Often human-friendly
development Version Numbers
Branches are cheap
Fast switching
A Repository may be created by:
Easy to “merge” into other branches
Cloning an existing one (git clone)
Easy to create, easy to destroy Creating a new one locally (git init)
See this guide for best practices
5
WHAT IS A COMMIT?
Specific snapshot within the development tree
Collection of changes applied to a project’s files
Text changes, File and Directory addition/removal,
chmod
1.x
c4
(branch)
A d d00
dC a
oo
lF
ea
t ur
1.0
fd e1
9
(tag)
8f6
Ad 45f Ch 943
dS an
tu f ge
f the
TAGS, OH MY!
AP
I
e1
9f Ad 1bd4
Bu d132 dC
gf oo
ix lF
1 ea
tur
9e e2
Ad 5ed3
2.x
dC
(branch)
oo
lF
ea
tu r
f1c e3
Ch 2b8
an
1.1
ge
(tag)
af1 the
Bu c2b AP
gf
ix I(
2 ag
ain
61 )
BRANCHES, COMMITS, AND
Ad 9cec
dS
tuf
f
7
TERMINOLOGY
Working Files Use “git diff” to see which changes exist.
Files that are currently on your File System
Use “git add” to tell Git that a file’s
The Stage (also called the “index”) changes should be added to the stage.
Staging is the first step to creating a commit
Use “git status” to see the changes in your
The stage is what you use to tell Git which working files, as well as what changes
changes to include in the commit have been staged for the commit.
File changes must be “added” to the stage
explicitly Use “git commit” to convert all staged
Only changes that have been staged will be changes into a commit.
committed git commit -m “my commit message”
git commit -m “my commit message” -a
Checkout Will automatically stage all files tracked by the repo & add
Replace the current working files with those them to the commit.
from a specific branch or commit Please don’t do this.
8
A DISTRIBUTED VCS
What do we mean by distributed? Common Pattern:
Cloning a repository (repo) creates a full copy One canonical repository for the project (on
of that repo on your local machine. GitHub, for example)
You can fetch updates from non-local Every developer forks that repo on GitHub
repositories (e.g., repos on GitHub) A fork is simply creating a copy of the repo on that remote
system
A non-local repositories is a remote Every developer clones their own GitHub repo
When you clone a repository, a remote called to their local machine
origin is created for you automatically in your Every developer adds a remote pointing to the
local repo which points to the source repo. canonical (main, authoritative) repo, as well as
Remotes are local settings. They do not other dev repos as needed
become part of your commits. Devs work locally, push changes to their own
You may set up additional remotes. remote, then request that the canonical repo
Use case: Development teams, where each dev has their accept their changes via a pull request
own repository.
9
A DISTRIBUTED VCS
(VISUALIZED) Requ est
GitHub, BitBucket,
SourceForge,
l
Pul Canonical GitLab, CodePlex,
etc.
k for
for k
fork
Arlene Cindy
in
Bret
ma
ori
clo
et cin d
gin
r
ne
b
y
Action
GIT WORKFLOW
You pull from a remote to your local
repository.
A pull is a fetch and a merge
I prefer to use fetch and merge separately,
and avoid pull.
Merge conflicts must be fixed manually, If you cannot push your code to a remote,
and then added and committed. you probably need to first pull the latest
changes, resolve any existing merge
“git status” will show any merge conflicts. conflicts, then try to push again.
A successful merge creates a new commit Small commits are better than large ones!
automatically.
12
COMMON INDUSTRY
PROGRAMMER WORKFLOW
1. Choose a bug/feature to work on
2. Checkout the appropriate branch
The pull request is where other
3. Pull the latest additions from the programmers review your code & make
main repository comments/suggestions.
4. Create a branch for the bug/feature If changes are needed to your code, then
request repeat the process.
5. Do the coding necessary & commit
6. Push the changes to your remote Never
7. Create a pull request to main repo
13
PRACTICAL GUIDELINES
Do’s Don’ts
Make small, incremental commits (within Do not commit commented-out debug code.
reason) are good. Avoid monolithic commits at It’s messy. It’s ugly. It’s unprofessional.
all cost. Do not mix your commits. (e.g., Don’t commit
Use a separate branch for each new bug/feature two bugfixes at the same time.)
request. Do not commit sensitive information
Write nice commit messages. Otherwise, the (passwords, database dumps, etc.)
commit log is useless. Do not commit whitespace differences, unless
Use a .gitignore to keep cruft out of your repo. it is specifically needed.
Search engines are your friend. Someone else Do not commit large binaries.
has had the same question/mistake/situation as
you, and they have already asked the question
online. It’s probably on StackOverflow.
14
HELPFUL RESOURCES
Pro Git – free Apress ebook
Visualizing Git histories
Wikipedia on Version Control, with
definitions
My Git Cheat Sheet
Git Commit Etiquette for Junior Devs
https://www.codeschool.com/learn/git
Free course to walk you through basic Git
concepts
15