GIT: Content-addressable filesystem and Version Control System

GIT
Content-addressable ﬁlesystem
and
Version Control System

@tommyblue - www.tommyblue.it

From Nofu to Shogun
Standard presentation

This presentation

•

Introduction

•

Introduction

•

Basic commands

•

Git internals

•

Advanced commands

•

Basic commands

•

Git internals (optional)

•

Advanced commands

•

Fabbri’s problem-solving
Pizzu’s

GIT
Content-addressable ﬁlesystem +
Tools to manage them (porcelains) =
—————————————————
Version Control System

CVS/SVN use deltas

With long histories, becomes heavy to
calculate current ﬁles state

Git uses snapshots

•

A version is a tree (like a FS) using hashes as nodes

•

Every version is a snapshot of the full repository, with all files

•

A file is identified by a SHA-1 hash, depending on the file content

•

If the content doesn’t change, the hash is the same

The .git folder
Everything is in the .git folder (delete it to delete repo)
.git/
hooks/
info/
objects/
=>
refs/
=>
config
description
index
=>
HEAD
=>

repo content
commit objects’ pointers

stage infos
checkouted branch

Git objects
Git works like a key-value datastore
When you save an object in Git, it returns its hash
All the object are identiﬁed by an hash
Objects
!

Blob

Tree

Commit

TAG

Blob objects - 1
Essentially the committed ﬁle with its content
# Save a simple text file (without -w it calculates the hash)
$ echo 'test content' | git hash-object -w --stdin
d670460b4b4aece5915caf5c68d12f560a9fe3e4

# The created object (notice the folder structure)
$ find .git/objects -type f
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

# Extract the content using the hash as reference
$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
test content

Blob objects - 2
# New version of the file
$ echo 'version 1' > test.txt
$ git hash-object -w test.txt
83baae61804e65cc73a7201a7252750c76066a30

# Now there are two objects
$ find .git/objects -type f
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4

# Restore the old version
$ git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4 >
test.txt

Tree objects
Contains references to its children (trees or blobs), like a UNIX folder

Every commit (snapshot) has a diﬀerent tree

# Adds a file to the index (staging area)
$ git update-index --add --cacheinfo 100644
a906cb2a4a904a152e80877d4088654daad0c859 README
# Write the tree object (containing indexed/staged files)
$ git write-tree
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
$ git cat-file -t 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
tree
# Show the tree object content
$ git cat-file -p 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
100644 blob a906cb2a4a904a152e80877d4088654daad0c859
README
100644 blob 8f94139338f9404f26296befa88755fc2598c289
Rakefile
040000 tree 99f1a6d12cb4b6f19c8655fca46c3ecf317074e0
lib

Commit objects - 1
Commit message, other informations (GPG) and reference to a
tree object (through its hash)
# First commit object given a tree object (1f7a7a)
$ echo 'first commit' | git commit-tree 1f7a7a
fdf4fc3344e67ab068f836878b6c4951e3b15f3d

# Let’s check the commit content
$ git cat-file -p fdf4fc3
tree 1f7a7a472abf3dd9643fd615f6da379c4acb3e3a
author Tommaso Visconti <tommaso.visconti@drwolf.it> 1243040974 -0700
committer Tommaso Visconti <tommaso.visconti@drwolf.it> 1243040974 -0700

!
first commit

TAG objects
Lightweight tag
Like a commit with reference to a commit object (not a tree)

Annotated tag
Git creates a tag object and the ref tag pointing to its hash
$ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'test tag’

!
$ cat .git/refs/tags/v1.1
9585191f37f7b0fb9444f35a9bf50de191beadc2

!
$ git cat-file -p 9585191f37f7b0fb9444f35a9bf50de191beadc2
object 1a410efbd13591db07496601ebc7a059dd55cfe9
type commit
tag v1.1
tagger Tommaso Visconti <tommaso.visconti@drwolf.it> Mon Nov 25 15:56:23 2013

!
test tag

References - 1
Useful to avoid using and remembering hashes

Stored in .git/refs/

Text ﬁles just containing the commit hash

References - 2
Branches are references stored in .git/refs/heads
# Update master ref to the last commit
$ git update-ref refs/heads/master 1a410e

Lightweight tags are refs placed in .git/refs/tags
Remotes are refs stored in

.git/refs/remotes/<REMOTE>/<BRANCH>
!

The commit hash of a remote is the commit of that branch
the last time the remote was synchronized (fetch/push)

HEAD - 1
How GIT knows which branch or commit is checkouted?
# HEAD is a symbolic reference
$ cat .git/HEAD
ref: refs/heads/master
# Get HEAD value using the proper tool
$ git symbolic-ref HEAD
refs/heads/master
# Set HEAD
$ git symbolic-ref HEAD refs/heads/test
$ cat .git/HEAD
ref: refs/heads/test

HEAD - 2
HEAD generally points to the checked out branch
Committing in this situation means set a new hash to the
current branch and, as a consequence, HEAD points to it
HEAD can be moved with git reset
If HEAD points to a commit and not a branch, it’s the so
called Detached HEAD
Committing in this situation means advance HEAD to the
new commit hash, without modifying any branch

Detached HEAD - 1
$ git add .
$ git commit -m message1
[master (root-commit) 3065781] message1
1 file changed, 1 insertion(+)
create mode 100644 test.txt
$ cat .git/HEAD
$ cat .git/refs/heads/master
30657817081f6f0808bf37da470973ad12cb7593
$ echo prova > test2.txt
$ git add .
$ git ci -m test2
[master 33676f0] test2
create mode 100644 test2.txt
$ cat .git/HEAD
$ cat .git/refs/heads/master
33676f027d9c36c66f2a2d5d74ee1cbf3e1ff56b

Detached HEAD - 2
$ cat .git/HEAD
$ git checkout 30657817081f6f0808bf37da470973ad12cb7593
Note: checking out '30657817081f6f0808bf37da470973ad12cb7593'.

!
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

!
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

!
git checkout -b new_branch_name

!
HEAD is now at 3065781... message1
$ cat .git/HEAD
30657817081f6f0808bf37da470973ad12cb7593

Detached HEAD - 3
$ echo 'detached' > det.tx
$ git add .
$ git commit -m 'det commit'
[detached HEAD b843940] det commit
create mode 100644 det.txt
$ git log
commit b8439407b2524b55ceba814a9eef2ee92655a0bb
Author: Tommaso Visconti <tommaso.visconti@gmail.com>
Date:
Mon Nov 25 16:49:05 2013 +0100

!
det commit

!
commit 30657817081f6f0808bf37da470973ad12cb7593
Date:
Mon Nov 25 16:39:53 2013 +0100

!
message1

Detached HEAD - 4
$ git checkout master
Warning: you are leaving 1 commit behind, not connected to
any of your branches:

!
!

b843940 det commit

If you want to keep them by creating a new branch, this may be a good time
to do so with:

!
!

git branch new_branch_name b843940

Switched to branch 'master'
$ git log
commit 33676f027d9c36c66f2a2d5d74ee1cbf3e1ff56b
Date:
Mon Nov 25 16:40:31 2013 +0100

!
!

test2

commit 30657817081f6f0808bf37da470973ad12cb7593
Date:
Mon Nov 25 16:39:53 2013 +0100

!

message1

The b843940 commit
is gone.. :-(

Background: refspec
A refspec is a mapping between remote and local branch
An example is the fetch entry in a remote conﬁg:
[remote "origin"]
url = git@github.com:schacon/simplegit-progit.git
fetch = +refs/heads/*:refs/remotes/origin/*

Format: +<src>:<dst>
<src>: where those references will be written locally

<dst>: pattern for references on the remote side

+: (optional) update the reference even if it isn’t a fast-forward

Background: ancestry references
Given a ref (eg. HEAD):
•
•
•
•

HEAD^ is the ﬁrst parent of HEAD

HEAD^2 is the second parent (and so on..)

HEAD~ is identical to HEAD^1

HEAD~2 is is the parent of the parent of HEAD

^ is useful for merging, where a commit has two or more parents

Background: ranges
git log <refA>..<refB>
All commits reachable by refB that aren’t reachable by refA
Commits in refB not merged in refA
Synonyms:
git log ^refA refB
git log refB --not refA
git log refA refB ^refC
!

The last is useful when using more refs

Background: ranges
git log <refA>…<refB>
All commits either reachable by refB and refA

but not both of them
Commits to be merged between the two refs

Basic commands - 1
git add --interactive
$ git add -i
staged
1:
unchanged

unstaged path
+1/-1 lipsum

!
*** Commands ***
1: status 2: update 3: revert 4: add
untracked
5: patch 6: diff
7: quit
8: help

Really powerful, not really user-friendly

Basic commands - 2
git commit and commit message
Commit description (visible with —oneline) max 50 chars

!
Commit full message. Breakline at 72nd char
Buzzword buzzword buzzword buzzword buzzword buzzword buzzword
buzzword buzzword buzzword buzzword buzzword buzzword buzzword

!
Commit footer
Commands, eg:
fixes #<BUG>
ecc.

git commit --amend

Basic commands - 3
git log
# Short diff
git log --oneline

!
# Line diff between files
git log -p

# Diff stats without lines
git log --stat

!
# Pretty diff with tree
git log --pretty=format:'%h %s' --graph

!
# Word diff
git log -p —word-diff

git diﬀ
# Diff with remote
git diff HEAD..origin/master

.gitignore
# Exact match (absolute path)
/public/README

!
# All matches
public/README
READ*

Useful tools
git blame

git bisect

Show the author of each line

Find the problematic commit

git alias

git filter-branch

Create command aliases

Hard change of history 
to delete committed passwords

git format-patch

git request-pull

Create a patch ﬁle ready to be
sent to somebody

Implement pull-request workﬂow

Git stash
Save unstaged changes for future reuse
Create a branch from stash:
git stash branch <BRANCH>

git unstash doesn’t exist but:
git stash show -p stash@{0} | git apply -R

Create an alias to do it:
git config --global alias.stash-unapply '!git stash show -p | git apply -R'

Git reset
Move HEAD to speciﬁc state (e.g. commit)
--soft

Move only HEAD

--mixed Move HEAD and reset the staging
area to it (default)
--hard
Move HEAD and reset staging area
and working tree

git reset [option] <PATH>
Don’t move HEAD, but reset the PATH (staging area and working tree,
depending from option)

Push
git push <remote> <refspec>
refspec format => <src>:<dst>

git push origin master
git push origin development:master
git push origin :development
git help push

Fetch
Sync remotes status: git fetch <remote>
Uses .git/config to know what to update
[remote "origin"]
url = git@github.com:schacon/simplegit-progit.git
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*

After checking a remote status we can:
•
•
•

merge

rebase

cherry-pick

Pull
git pull origin master

=
git fetch origin
git merge origin/master
In both cases the master branch must be checkouted

Fast-forward merge
When a branch has commits which are direct predecessor
of the branch where we’re merging, this is a so called

fast-forward merge
To merge iss53 to master,
git just advances master
pointer to C3 without
creating a commit
object. This is a fastforward merge
Use merge --no-ff to force creation of a commit object

3-way merge
When the commit to be merged isn’t a direct predecessor
of the commit to merge into

C5 is a new commit object, including merge informations

Merge strategies
recursive: default when merging a
single head (can have sub-options)
octopus: default otherwise
resolve
ours
subtree

Rebase
The experiment’s
commits (C3) become
a single commit (as a
patch) C3’ which is
applied to master
It’s a rebase on experiment, then a FF merge on master

git
git
git
git

checkout experiment
rebase master # C3’ is created
checkout master
merge experiment # FF merge

Advanced rebase

We want C8 and C9 on master

Advanced rebase
git rebase --onto master server client
“Check out the client branch, ﬁgure out the patches from the common ancestor
of the client and server branches, and then replay them onto master”

Advanced rebase
Now perform a simple fast-forward merge on
master to advance it to C9’

C8’+C9’, originally made on C3, on C6 can break code!

Advanced rebase

With rebase the rebased commits become only one,
the commit history is lost

With interactive rebase is possible to edit history,
changing commit messages, squashing, splitting,
deleting and reordering commits

Cherry-pick

$ git checkout master
$ git cherry-pick e43a6f
Finished one cherry-pick.
[master]: created a0a41a9: “Cherry-pick example"
3 files changed, 17 insertions(+), 3 deletions(-)

Submodules
Use other repositories in your own
e.g. an external lib in ./lib/<libname>
git submodule add [-b <BRANCH>] <REPO> <PATH>
Submodules track a commit or a branch (from 1.8.2)
Submodules informations are stored in .gitmodules
and .git/modules.
.gitmodules must be committed at the beginning and after a
submodule update

Subtree merging
Can be used in place of submodules
Is a way to track a branch in an another branch folder
RepositoryFolder/

|_lib/

|_libA/

RepositoryFolder is on
master branch and libA/ is
the lib_a branch

Workﬂow examples

http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project

Git ﬂow
master contains production code
and is tagged with release
development contains dev code
create a new feature from
development
the feature merges on
development
development becomes a release
a release merges on master
an hotﬁx is a branch from master
and merges on master and
development

If you write code on master or development, you’re wrong!

GIT: Content-addressable filesystem and Version Control System

Recommended

More Related Content

What's hot (20)

Similar to GIT: Content-addressable filesystem and Version Control System (20)

Recently uploaded (20)

GIT: Content-addressable filesystem and Version Control System