Introduction to
Surabhi Gupta
Fast, open-source, distributed
source control system.
Client-Server vs Distributed models
VCS SERVER
Version 1
Version 2
Version 3
Version 1 Version 1
Version 1
Version 2
Version 3
Version 1
Version 2
Version 3
Version 1
Version 2
Version 3
Advantages of Git over P4
Perforce (Client-Server) Git (Distributed)
Version management system Source control system
Slow due to network latency and
increased dependency on server calls
Fast! Work locally, offline
Intermediate work cannot be easily
saved to P4
Various checkpoints for saving
intermediate work
Difficult to experiment Facilitates experimentation
A merger is typically responsible for
merging between branches
The developer is responsible for
merging their branch into master
Server for Git
❖ Github, Stash, CloudForge, etc are code management
and collaboration tools for Git repos!
❖ They provide fine grained control over permissions,
audit of commit history.!
❖ The distributed model of Git facilitates open source
projects since individuals can easily fork off repos and
merge the changes back in.
Scope of the talk
❖ Various roles require different levels of expertise in Git:!
❖ Manager !
❖ Software Engineer/QA Engineer !
❖ Merger/Release Engineer — consumer of git scripts!
❖ Develop scripts that extend git functionality — deep dive into git
internals.!
❖ We will cover concepts and commands that will come in handy in your
day-to-day work as a developer.!
❖ This talk is a road map of the Git world. Hopefully, it will whet your
appetite for exploring the trails.
Roadmap
❖ Content hashing!
❖ Blobs to Branches!
❖ Staging and committing !
❖ Remotes and pull requests!
❖ Merge conflicts!
❖ Git resources
Content Hashing
❖ Contents are referenced using their hashes: !
sha1(“blob ” + fileSize + “0” + fileContent)!
echo “foobar” > foo.txt

git hash-object foo.txt = sha1 (“blob 70foobarn”)!
323fae03f4606ea9991df8befbb2fca795e648fa!
❖ Fun fact: Renames are not stored in the repo. They’re
computed by commands such as git diff, git merge, etc.
Blobs to trees
❖ A tree is an object that stores !
a) blob!
b) subtree!
❖ Each of these contain metadata about their mode, type and
name!
❖ A tree object can contain objects of type “blob” or “tree”.!
❖ Example modes: 100755 means it’s an executable file, 120000
specifies a symbolic link
Git Internals: Tree
blob
blob
tree
Commit from trees
❖ A commit is a pointer to a tree!
❖ It is pointed to by one or more parent commits!
❖ It also contains metadata about its:!
1) Author !
2) Committer
Git Internals: Commit
parent!
commit
tree’
tree blob’
blob
commit
Commits to trees
parent!
commit
commit
tree
tree blob
blob
tree’
blob’
blob
Reuse of objects
tree
tree blob
blob
tree’
blob’
blob
parent!
commit
commit
Reusing blob/tree !
from elsewhere
or
… under-the-hood!
object!
sharing
Reuse of objects within a tree
“B”“A” “C”
“A”
tree
Blobs can be shared within!
a single tree.
Multiple parents
P1 P2
C
Multiple parents
T1
B1
T2
B2
T3
B3
P1 P2
C
Commits with multiple parents!
have a one-to-one relationship with trees, !
similar to commits with single parents
Branch - pointer to a commit
Master
git branch
HEAD - pointer to the current commit
HEAD
git checkout C
Master
HEAD
Master
C C
All your codebase are belong to me
❖ git clone!
❖ git log
Version 1
Version 2
Version 3
Version 1
Version 2
Version 3
Version 1
Version 2
Version 3
Server/Remote
You Peer
Our first commit
❖ echo “May the 4th” >> “force.txt”!
❖ git status!
❖ git add force.txt!
❖ git diff —cached!
❖ git commit -m “May the force be with you”
C3
C2
C1
C4
C3
master
C2
C1
You
Remote
remotes/master
master
C4
C3
C2
C1
You
git push
Remote
C4
C3
C2
C1
origin/master
master
master
What if I made a mistake?
Undo unstaged changes
force.txt
git checkout — force.txt
echo “new” >> force.txt
Committed
Staging!
Area
Unstaged!
changes
Unstage changes
force.txt
force.txt
git reset HEAD force.txt
git add force.txt
Committed
Staging!
Area
Unstaged!
changes
Uncommit changes
force.txt
force.txt
git reset —soft HEAD^
git commit -m
“Second commit”
Committed
Staging!
Area
Unstaged!
changes
Typical workflow
Typically, if your team has more than one person, you
wouldn’t commit to master directly. Recommended
workflow:!
1) Check out a private branch!
2) Commit to the branch, and regularly push to remote.!
3) When the work is complete, get a code review (likely
via a pull request) and merge the branch into master
Step 1: Create a new branch
git branch bugFix
HEAD
master
bugFix
HEAD
master
Checkout said branch
git checkout bugFix
bugFix
HEAD
master
bugFix
HEAD
master
Current branch
Step 2: Feature development
HEAD
master
B
CbugFix
master
B
CbugFix
D
Local Remote
A A
Step 3: Merge into master
A
master
B
CbugFix
D
Remote
A
masterbugFix
B
E
C
New merge commit E
Remote after!
merge
D
gitk - show git graph
Can we do better?
A
master
B
CbugFix
D
We would like to modify the
commit history to make it
appear as if bugFix was based
on commit D all along!
Rebase to the rescue
❖ Rebase allows you to replay a series of commits on top
of a new base commit. !
❖ Helps keep the commit history clean
Rebase in action
A
master
B
CbugFix
D
bugFix
A
D
C*
B*
git rebase master bugFix
B
C

master
Merge bugFix with master
A
D
E
masterbugFix
A
master
C*
bugFix
B*
D
C*
B*
Merging the rebased branch bugFix !
into master. This merge is typically!
triggered in the code management tool!
(Github, Stash, etc) after a pull request!
is approved.
Merge conflicts
❖ Situation: Conflicting modifications to a file that has
changed since we checked it out!
❖ Two options: merge, rebase!
❖ On a private branch, it is recommended that you rebase. !
❖ On a shared branch, merge is the way to go.
Changing the commit history
❖ “git commit —amend” rewrites the your last commit
with the current changes instead of creating a new
commit!
❖ Interactive rebase: git rebase -i!
❖ Swiss army knife of modifying history!
❖ Allows you to amend, squash, split, or skip commits
as they're applied
Many roads, one destination
❖ There are often multiple ways to accomplish a task in Git, for example:
git branch <branchName>

git checkout <branchName>
 git checkout -b <branchName>
git checkout -b <branchName>
<remoteName>/<remoteBranch>
git branch --track <branchName>
<remoteName>/<remoteBranch>
git fetch!
git merge
git pull
Give It a Try
Git Resources
❖ Learn by playing: http://pcottle.github.io/learnGitBranching/!
❖ Atlassian tutorial: https://www.atlassian.com/git/tutorials/
setting-up-a-repository/!
❖ Free CodeSchool course on Git: https://www.codeschool.com/
courses/git-real!
❖ StackOverflow is a great resource: http://stackoverflow.com/
questions/2706797/finding-what-branch-a-commit-came-from!
❖ Pro Git by Scott Chacon and Ben Straub: http://git-scm.com/
book/en/v2
Closing thoughts
❖ Git is a powerful source control tool designed to
maximize the efficiency of the developer. Take full
advantage of it!!
❖ We’ve only explored the tip of the iceberg. May the
power of Git be with you.

Git basics

  • 1.
  • 2.
  • 3.
    Client-Server vs Distributedmodels VCS SERVER Version 1 Version 2 Version 3 Version 1 Version 1 Version 1 Version 2 Version 3 Version 1 Version 2 Version 3 Version 1 Version 2 Version 3
  • 4.
    Advantages of Gitover P4 Perforce (Client-Server) Git (Distributed) Version management system Source control system Slow due to network latency and increased dependency on server calls Fast! Work locally, offline Intermediate work cannot be easily saved to P4 Various checkpoints for saving intermediate work Difficult to experiment Facilitates experimentation A merger is typically responsible for merging between branches The developer is responsible for merging their branch into master
  • 5.
    Server for Git ❖Github, Stash, CloudForge, etc are code management and collaboration tools for Git repos! ❖ They provide fine grained control over permissions, audit of commit history.! ❖ The distributed model of Git facilitates open source projects since individuals can easily fork off repos and merge the changes back in.
  • 6.
    Scope of thetalk ❖ Various roles require different levels of expertise in Git:! ❖ Manager ! ❖ Software Engineer/QA Engineer ! ❖ Merger/Release Engineer — consumer of git scripts! ❖ Develop scripts that extend git functionality — deep dive into git internals.! ❖ We will cover concepts and commands that will come in handy in your day-to-day work as a developer.! ❖ This talk is a road map of the Git world. Hopefully, it will whet your appetite for exploring the trails.
  • 7.
    Roadmap ❖ Content hashing! ❖Blobs to Branches! ❖ Staging and committing ! ❖ Remotes and pull requests! ❖ Merge conflicts! ❖ Git resources
  • 8.
    Content Hashing ❖ Contentsare referenced using their hashes: ! sha1(“blob ” + fileSize + “0” + fileContent)! echo “foobar” > foo.txt
 git hash-object foo.txt = sha1 (“blob 70foobarn”)! 323fae03f4606ea9991df8befbb2fca795e648fa! ❖ Fun fact: Renames are not stored in the repo. They’re computed by commands such as git diff, git merge, etc.
  • 9.
    Blobs to trees ❖A tree is an object that stores ! a) blob! b) subtree! ❖ Each of these contain metadata about their mode, type and name! ❖ A tree object can contain objects of type “blob” or “tree”.! ❖ Example modes: 100755 means it’s an executable file, 120000 specifies a symbolic link
  • 10.
  • 11.
    Commit from trees ❖A commit is a pointer to a tree! ❖ It is pointed to by one or more parent commits! ❖ It also contains metadata about its:! 1) Author ! 2) Committer
  • 12.
  • 13.
  • 14.
    Reuse of objects tree treeblob blob tree’ blob’ blob parent! commit commit Reusing blob/tree ! from elsewhere or … under-the-hood! object! sharing
  • 15.
    Reuse of objectswithin a tree “B”“A” “C” “A” tree Blobs can be shared within! a single tree.
  • 16.
  • 17.
    Multiple parents T1 B1 T2 B2 T3 B3 P1 P2 C Commitswith multiple parents! have a one-to-one relationship with trees, ! similar to commits with single parents
  • 18.
    Branch - pointerto a commit Master git branch
  • 19.
    HEAD - pointerto the current commit HEAD git checkout C Master HEAD Master C C
  • 20.
    All your codebaseare belong to me ❖ git clone! ❖ git log Version 1 Version 2 Version 3 Version 1 Version 2 Version 3 Version 1 Version 2 Version 3 Server/Remote You Peer
  • 21.
    Our first commit ❖echo “May the 4th” >> “force.txt”! ❖ git status! ❖ git add force.txt! ❖ git diff —cached! ❖ git commit -m “May the force be with you”
  • 22.
  • 23.
  • 24.
    What if Imade a mistake?
  • 25.
    Undo unstaged changes force.txt gitcheckout — force.txt echo “new” >> force.txt Committed Staging! Area Unstaged! changes
  • 26.
    Unstage changes force.txt force.txt git resetHEAD force.txt git add force.txt Committed Staging! Area Unstaged! changes
  • 27.
    Uncommit changes force.txt force.txt git reset—soft HEAD^ git commit -m “Second commit” Committed Staging! Area Unstaged! changes
  • 28.
    Typical workflow Typically, ifyour team has more than one person, you wouldn’t commit to master directly. Recommended workflow:! 1) Check out a private branch! 2) Commit to the branch, and regularly push to remote.! 3) When the work is complete, get a code review (likely via a pull request) and merge the branch into master
  • 29.
    Step 1: Createa new branch git branch bugFix HEAD master bugFix HEAD master
  • 30.
    Checkout said branch gitcheckout bugFix bugFix HEAD master bugFix HEAD master Current branch
  • 31.
    Step 2: Featuredevelopment HEAD master B CbugFix master B CbugFix D Local Remote A A
  • 32.
    Step 3: Mergeinto master A master B CbugFix D Remote A masterbugFix B E C New merge commit E Remote after! merge D gitk - show git graph
  • 33.
    Can we dobetter? A master B CbugFix D We would like to modify the commit history to make it appear as if bugFix was based on commit D all along!
  • 34.
    Rebase to therescue ❖ Rebase allows you to replay a series of commits on top of a new base commit. ! ❖ Helps keep the commit history clean
  • 35.
  • 36.
    Merge bugFix withmaster A D E masterbugFix A master C* bugFix B* D C* B* Merging the rebased branch bugFix ! into master. This merge is typically! triggered in the code management tool! (Github, Stash, etc) after a pull request! is approved.
  • 37.
    Merge conflicts ❖ Situation:Conflicting modifications to a file that has changed since we checked it out! ❖ Two options: merge, rebase! ❖ On a private branch, it is recommended that you rebase. ! ❖ On a shared branch, merge is the way to go.
  • 38.
    Changing the commithistory ❖ “git commit —amend” rewrites the your last commit with the current changes instead of creating a new commit! ❖ Interactive rebase: git rebase -i! ❖ Swiss army knife of modifying history! ❖ Allows you to amend, squash, split, or skip commits as they're applied
  • 39.
    Many roads, onedestination ❖ There are often multiple ways to accomplish a task in Git, for example: git branch <branchName>
 git checkout <branchName>
 git checkout -b <branchName> git checkout -b <branchName> <remoteName>/<remoteBranch> git branch --track <branchName> <remoteName>/<remoteBranch> git fetch! git merge git pull
  • 40.
  • 41.
    Git Resources ❖ Learnby playing: http://pcottle.github.io/learnGitBranching/! ❖ Atlassian tutorial: https://www.atlassian.com/git/tutorials/ setting-up-a-repository/! ❖ Free CodeSchool course on Git: https://www.codeschool.com/ courses/git-real! ❖ StackOverflow is a great resource: http://stackoverflow.com/ questions/2706797/finding-what-branch-a-commit-came-from! ❖ Pro Git by Scott Chacon and Ben Straub: http://git-scm.com/ book/en/v2
  • 42.
    Closing thoughts ❖ Gitis a powerful source control tool designed to maximize the efficiency of the developer. Take full advantage of it!! ❖ We’ve only explored the tip of the iceberg. May the power of Git be with you.