an introduction to the git revision control system

An Introduction to theGit 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

cd \core\users\jadamczewski \code

Git• Changing branches usually

happens in one working copy

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 branchgit add, git rm, git mv

– Commit the files to the repository.git commit

• http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows shows what some real world distributed workflows look like

• http://git-scm.com/book/en/Distributed-Git-Maintaining-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 commitgit checkout

# merge multiple branchesgit merge

# reapply changes to a different # commitgit rebase

# rewrite history git rebase –i

# stage a file for commitgit add

# stage parts of files for commitgit add -i

# show the current state of the # working dir. Lists new and modified # files and files staged for commitgit status

# list commits in a branch from the # most recentgit log

# list files know to git in a branchgit ls-files

# search through files known to git – # very fast!git grep

# show changes between thingsgit diff

# get a basic graphical UIgitk

# copy commits from one branch to anothergit cherry-pick