An Introduction to the
Git Revision Control System
Jonathan Adamczewski
This presentation is not
• One VCS is better than another
• Me telling you that you should use Git
• Anyone suggesting that Insomniac will stop
using Perforce
This presentation is an introduction to Git:
• How it works
• Ways that it is or isn’t like Perforce
GIT VS PERFORCE
FIGHT.
Perforce
• Submit
Git
• Commit
Perforce
• Submit
-> Changelist
Git
• Commit (verb)
-> Commit (noun)
Perforce
• Centralized storage
• Centralized history
• Centralized collaboration
• Connection to server is
required
• p4 edit
Git
• Distributed storage
• Distributed, divergent
histories
• Peer to peer collaboration
• Central server optional
• ---
Perforce
• Files are versioned
• Server-wide incrementing
changelist number
Git
• Entire working copy is
versioned (snapshots)
• Every commit has a unique
SHA-1 hash from:
–
–
–
–
Parent commit(s)
Description
Author
Content
Perforce
• Client view maps file in
depots to local files on
client system
Git
• Every clone of a git
repository stores the entire
history of the repository
“A Perforce branch is a branch of file hierarchy.
A Git branch is a branch of workspace history.”
Perforce
• One set of local changes per
file
• No history stored outside of
the server
Git
• Create arbitrary file
histories and store them in
local branches
Perforce
• Branching
– Cost scales with size
– Expressed as a duplication
and divergence in the file
hierarchy
• Branch cost depends on the
size & number of files being
branched
Git
• Branching is
– Very cheap
– Expressed as a new pointer
associated with a single
commit
• Branch cost is constant:
One 41 byte file per branch.
Perforce
• Changing branches usually
means moving to a different
directory
Git
• Changing branches usually
happens in one working
copy
cd \core\users\jadamczewski
\code
git checkout some_branch
Perforce
• One set of local changes per
file
• Looks like:
– File can be in only one
pending changelist
– Easy to miss files when
submitting
Git
• Arbitrary local histories
• Looks like
– Nothing quite like
pending changelists
– Modified files are staged and
then committed
With great power comes great blahblablah
Perforce
• One set of local changes per
file
• One resolve per file before
submit
Git
• Potentially many local
changes per file
• Potentially many resolves
per file before submit
– Not usually that bad
– git rebase
Perforce
• A mighty server dedicated
to storing all the versions of
all the files
• Handles anything and
everything – text, binary,
large, small
Git
• Every user’s machine is
their git server – not
dedicated to just git
• Not good with large,
frequently changing binary
files
– Repo size increases quickly
Perforce
• shelve
– For backup and collaboration
– Stores a copy on the server
– Allows local revert without
losing changes
• Generally inconvenient to
move uncommitted changes
between branches
Git
• branch/commit
– Store a copy in the local repo
• clone or push
(or just copy the repo)
– Duplicate the [contents of]
the repo somewhere else
– For backup and collaboration
• Many ways to get commits
from another repo
Perforce
• shelve
– Sometimes just to stash some
changes easily off to the side
Git
• stash
– Just to stash some changes
easily of to the side
– stashed changes are kept in a
stack, and can be re-applied
later
Perforce
• Submit means there is
redundancy – the data
exists on your machine and
the server.
Git
• Commit only stores changes
on your local HDD
• Need to push, copy, or
otherwise share the commit
to have a redundant copy
• Git directory structure:
repo_dir/
.git/<git’s many files>
your workspace
• How to commit a file:
– Make changes to files in the working directory.
Does not require marking for edit.
(edit, add, delete, copy, etc)
– Stage the files for commit.
Does not affect the recorded history for the
current branch
git add, git rm, git mv
– Commit the files to the repository.
git commit
• http://git-scm.com/book/en/Distributed-GitDistributed-Workflows shows what some real
world distributed workflows look like
• http://git-scm.com/book/en/Distributed-GitMaintaining-a-Project has information about
maintaining repos in a distributed
environment
Some commonly used git commands
# reset contents of working dir
git reset
# manipulate branches
git branch
# populate working dir with a commit
git checkout
# merge multiple branches
git merge
# reapply changes to a different
# commit
git rebase
# rewrite history
git rebase –i
# stage a file for commit
git add
# stage parts of files for commit
git add -i
# show the current state of the
# working dir. Lists new and modified
# files and files staged for commit
git status
# list commits in a branch from the
# most recent
git log
# list files know to git in a branch
git ls-files
# search through files known to git –
# very fast!
git grep
# show changes between things
git diff
# get a basic graphical UI
gitk
# copy commits from one branch to another
git cherry-pick