Small presentation about how GIT works under the hood

1. What GIT is!
Harry Kalogirou
twitter: @harkal

2. What GIT is
• The most widely used version control system in the world
• At the same time, the most misunderstood version control system
• Created by Linus Torvalds to handle the Linux kernel source code

3. -John Wishfulthinking
“GIT is simpler than you think”

4. GIT is not SVN
• Τrying to apply past knowledge of SVN to
GIT is the root of all evil
• Subversion fits in nicely with our existing
computing paradigms. Everybody
understands files and folders. Everybody
knows that revision #10 was the one after
#9 and before #11.
• That is the reason why it’s all rainbows and
unicorns only until you start talking about
branching, merging, re-basing, multiple
remotes, remote-tracking branches,
detached HEAD states, etc
Αποτάξομεν το SVN?!

5. GIT is not SVN
• GIT looks so complex, but only if you try to look at it through Subversion
• GIT looks very simple once you understand how it really works underneath
• And suddenly a “no-fast-forward merge” makes sense and a “rebase pull”
makes you look smart in front of your friends.

6. Understanding GIT
• So the key to understanding GIT is to
figure out the simple things that GIT
does under the hood
• How it stores data
• And how all you do translates to those
simple things

7. How GIT stores its data?
• Where are all the files, commits, tags, etc stored?
• It must be very complex, right?NO

8. What is at the core of GIT
• At the core of GIT, like other VCS, is the repository
• That repository is a SIMPLE key-value datastore, where everything is
stored
• All commits, files, tags and file system tree nodes are different types of
objects living in this repository.
• All indexed by their SHA-1 hash
• All live under .git/!
• The whole repository is stored under that directory. There is no central
repository. That is the repository.

9. What kind of objects are there?
• Blobs
• Tree objects
• Commit objects
• Tag objects
• References

10. Example
• Consider this simple repository:
README
src/
src/main.c
This would be represented by two tree objects:
• one for the root directory
• and another for the src/ directory
!
And two blob objects:
• one for the contents of the file README
• and another for the file main.c

11. Example
So eventually we have 4 objects in our key/value store, each
with its own SHA-1 key
!
These are actually files under .git/objects *
!
Issuing a “find .git/object -type f” command reveals the
secrets:
*as Linus was initially too bored to actually make a key/value store and used the filesystem
Charilaos-MacBook-Pro:test harkal$ find .git/objects -type f
.git/objects/b8/a08da3d1bbc3ab168a10859f34900d87be1de2
.git/objects/ba/e4c2f5634a0aa40b4ba7c271597d8a716e8116
.git/objects/cb/3f7482fa46d2ac25648a694127f23c1976b696
.git/objects/d3/ea3e42ec65b3606a9d9db8bba9be5ed8044f16

12. What a commit is
• A commit is just another object that contains:
• The SHA-1 hash of the tree it talks about
• The SHA-1 hashes of the parent commits
• the author (name, email, and time)
• the commiter (name, email, and time)
• the comments you provide
• As with all objects the above contents are hashed and stored under .git/objects.
That hash is the hash you use to reference that commit

13. That is basically it
You can use git now in all its power…
as long as you enjoy using hashes like this:
b8a08da3d1bbc3ab168a10859f34900d87be1de2
• Most of the rest is making it more human

14. References
• To save you from having to memorize hashes, GIT has references,
or “refs”.
• A reference is simply a file stored somewhere in .git/refs,
containing the hash of a commit object.
• Branches, tags, remote branches, HEAD are all just references

15. So putting it in perspective
• Your “develop” and “master” branches are just two files under .git/
refs, that point to a simple commit.
• To checkout that: It gets the commit, and recurses the tree it points
to and create the files.
• To get the commit history line of that branch: It follows all parent
commits in that commit.

16. So putting it in perspective
• What branch you are on? Just a special reference called “HEAD”
• Does HEAD not point to a branch but a simple commit? Then you
are in detached head state

17. So putting it in perspective
• All GIT’s commands and cryptic, difficult to understand notions,
fiddle arround with just these objects.
• No need to map it to any
SVN notion
• You just need a workflow
that you follow, to keep it
sane.
• There is no spoon!

18. Ευχαριστώ :)
With great power comes great responsibility
— Peter Parker