5. 5
Version control is a system that records
changes to a file or set of files over time so that
you can recall specific versions later.
Definition
Quelle: ProGit, 2nd edition by Chacon & Straub
7. 7
Source Code Control System (SCCS)
• early 1970s by M. J. Rochkind
• repository with file locking: check out with/without lock
Revision Control System (RCS)
• early 1980s by Walter F. Tichy
• forward and reverse delta concepts for the efficient storage of
different file revision
Local version control
9. 9
Concurrent Version System (CVS)
• 1986 by Dick Grune
• CVS gave each developer write permission in his or her private
working copy
• automatic merge of changes by different developers unless the
same line was changed conflict
Subversion (SVN)
• 2001
• committed changes atomically and had significantly better support
for branches
Centralized version control
10. 10
Distributed version control
Server Computer
Version Database
Version 3
Version 2
Version 1
Computer B
Version Database
Version 3
Version 2
Version 1
File
Computer A
Version Database
Version 3
Version 2
Version 1
File
11. 11
BitKeeper and Mercurial
• no central repository
• provide each developer with his own
copy
Mercurial and Monotone
• use hash fingerprints to uniquely identify
a file’s content
Distributed version control
12. 12
Linux kernel project
• 1991–2002: patches and archived files by email
• 2002: BitKeeper
• 2005: BitKeeper no longer usable free of charge
• April 2005: Linus Torvalds started Git
• Starting April 20 Linux kernel project uses Git (6,7 million lines of
code!)
Git has evolved and matured to be
• easy to use
• incredibly fast
• efficient with large projects
• incredible branching system for non-linear development.
The history of Git
13. 13
Git became self-hosted on April 7 with this commit:
Git‘s birth
commit e83c5163316f89bfbde7d9ab23ca2e25604af29
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Apr 7 15:13:13 2005 -0700
Initial revision of "git", the information manager
from hell
33. 33
Classical VCS
Storing data as changes to a base
version of each file
Version 1
File A ∆1
Checkins over time
Version 2 Version 3 Version 4 Version 5
∆2
∆1 ∆2File B
File C ∆1 ∆2 ∆2
34. 34
Git‘s way
Storing data as a snapshots of the
project over time.
Version 1
File A A1
Checkins over time
Version 2 Version 3 Version 4 Version 5
A2
B1 B2File B
File C C1 C2 C3
A2A1
B B
C2
35. 35
Git‘s way
If a file did not change only a link
to the file is stored
Version 1
File A A1
Checkins over time
Version 2 Version 3 Version 4 Version 5
A2
B1 B2File B
File C C1 C2 C3
A2A1
B B
C2
36. 36
• Everything in Git is check-summed before it is stored
• Checksum used for reference Integrity!
• All objects are stored compressed in the Git Object Database and
referenced by the SHA-1 value of its contents (plus a small header)
SHA-1 References
commit e83c5163316f89bfbde7d9ab23ca2e25604af29
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Apr 7 15:13:13 2005 -0700
Initial revision of "git", the information manager
from hell
37. 37
• Everything in Git is check-summed before it is stored
• Checksum used for reference Integrity!
• All objects are stored compressed in the Git Object Database and
referenced by the SHA-1 value of its contents (plus a small header)
• SHA-1 hash: 40-character hexadecimal string:
24b9da6552252987aa493b52f8696cd6d3b00373
SHA-1 References
39. 39
git add README hello.abap LICENSE
git commit -m “Initial commit”
Git commit
• One commit with pointer to the tree and
the commit metadata
• One tree: commited content & which files
are stored in which blob
• Three blobs for the content of each file
40. 40
a commit and its tree
commit
tree: 92ec2
author: Hendrik
commiter: Hendrik
«Initial commit»
tree
blob: 5b1d3 README
blob: 911e7 hello.abap
blob: cba0a LICENSE
blob
Hello Munich! This is
a README file for the
project….
blob
REPORT ‘Hello’.
WRITE ‘Hello sitMUC’.
blob
BPL Agreement
Beer Public License..
911e7
5b1d3
cba0a
92ec298ca9
Git commit
41. 41
Git commit
commits and parents
911e7
5b1d3
cba0a
92ec298ca9
commit
tree: 92ec2
parent:
author: Hendrik
commiter: Hendrik
Initial commit
Snapshot A
commit
tree: 184ca
parent: 98ca9
author: Hendrik
commiter: Hendrik
Bug fix #4711
Snapshot B
commit
tree: 0de24
parent: 34ac2
author: Hendrik
commiter: Hendrik
Feature request #007
Snapshot C
98ca9 34ac2 f30ab
43. 43
Git branch
a branch and its commit history
911e7
5b1d3
cba0a
92ec298ca9
98ca9
Snapchot A
34ac2
Snapchot B
f30ab
Snapchot C
v1.0 master
HEAD
Tag
Pointer to a specific commit
56. 56
Git merge
Three snapshots used in a typical merge
911e7
5b1d3
cba0a
C0 C1 C2
testing
C3
C4 C5
master
Common
Ancestor Snapshot to
Merge Into
Snapshot to
Merg In
58. 58
Git commit consists of 2 things:
1. pointer to the state of your code at some
moment in time
2. zero or more pointers to „parent“ commits
a Git commit is a node in a graph.
Git repo is one giant graph
59. 59
• Everything in Git is check-summed before it is stored
• Checksum used for reference Integrity!
• All objects are stored compressed in the Git Object Database and
referenced by the SHA-1 value of its contents (plus a small header)
• SHA-1 hash: 40-character hexadecimal string:
24b9da6552252987aa493b52f8696cd6d3b00373
Creating a branch is nothing more than just
writing 40 characters to a file
SHA-1 References
95. 95
git pull
update & merge
update local repository to the
newest commit – fetch and merge
changes
96. 96
git merge <branch>
update & merge
merge another branch into your
active branch (e.g. master) and
create a new commit (if there are
no conflicts)
108. 108
git fetch origin
git reset --hard origin/master
replace local changes
drop all your local changes and
commits, fetch the latest history
from the server and point local
master branch at it