Transcript Git - Eric Lawless

Distributed Version Control

Old-school version control like RCS
Image stolen from http://progit.org/book/ which is really good, go read it.

This is how Subversion works
Image stolen from http://progit.org/book/ which is really good, go read it.

This is how Git works
Image stolen from http://progit.org/book/ which is really good, go read it.


Because it has been mandated that you care
about version control by Prof. Laurendeau
Because you will use version control at every
single coding job you get in the real world
 If your company doesn’t have version control in place,
that’s a huge warning sign


Because it will change the way you think about
programming, for the better
Because it stops you from completely screwing
yourselves the day before an iteration is due


Let’s install Git and try some things out.
Linux: use your favourite package manager
 Ubuntu: aptitude install git

Windows: use the MSysGit installer
 http://code.google.com/p/msysgit/

Mac: use the OS X installer
 http://code.google.com/p/git-osx-installer/

Read Pro Git, it’s excellent and free
 http://progit.org/book/


Git is extraordinarily powerful and you’ll be a
better programmer if you take the time to
understand it
If in doubt, always use the built in manual
 Every git command has a --help flag
 e.g. git cherry-pick --help
Seriously go read http://progit.org/book/.

Let’s tell Git our name and email address
 It attaches these to any commits we make so
people know who to kill for breaking the build an
hour before an iteration is due


git config --global user.name “Your Name”
git config --global user.email “[email protected]”
 --global sets the variable for your OS user
▪ --system sets the variable for all users on your machine
 Omit the --global and --system flags to set a git
config variable for just this repository

git init
 Creates a local, empty git repository in the folder
where the command is run
 Creates a .git folder for the guts of the repository
▪ Only one .git folder, at the root of your repository
▪ This is way nicer than creating a new .svn folder for
every single subfolder in your repository

We’ll go over how to work with other people
on a remote repository soon
Image stolen from http://progit.org/book/ which is really good, go read it.

Crazy important! Memorize this!
 The working directory consists of the actual files
and folders on your machine
 The staging area lets you build commits out of
snapshots taken of the files and folders in your
working directory
 The repository maintains a collection and
complete hierarchical history of all commits

git status
 Shows you the state of your staging area and of
your working directory

git log
 Shows a commit history of your repository

git diff
 Shows changes between commits, your working
directory, the staging area, etc.
 git diff --help to learn more
Or you could just go read http://progit.org/book/ and you’ll be an expert.

git add file
 Adds a snapshot of file to your staging area
▪ You can change file and the snapshot will remain as it is

git rm file
 Removes the file snapshot from your staging area
and deletes file from your working directory

git rm --cached file
 Removes the file snapshot from your staging area
while keeping file in your working directory intact


Tells Git which files to ignore outright
Uses glob syntax for pattern matching
 There’s a decent summary of glob syntax at
linux.about.com/library/cmd/blcmdl7_glob.htm

Git adds re-inclusion rules with !pattern
 “Include any files matched by pattern, even if
they’ve been ignored by a previous pattern.”

There’s a sample .gitignore on the website
 Stack Overflow is a good source of .gitignore files

git commit -m “your message”
 Creates a commit from the contents of your
staging area and adds it to the repository
 -m “your message” sets the commit message

If we keep adding commits we get a linked list
that represents the history of our repository
 gitk --all gives a graphical history of all branches
 Leaving out the --all shows just this branch
And the book at http://progit.org/book/ has a whole bunch more information. Read the damn book!

Branching allows us to create a tree of
commits instead of a linked list
 Merging will let us turn this into a DAG

Easy, painless branching is the most
important and powerful feature of Git
 Give each new feature its own branch, which can
be merged back into the main (master) branch
after it’s been completed and is stable


Git maintains a pointer to the current checked
out branch, called HEAD
git branch newbranch
 Creates a new branch starting at the current commit,
but does not move the HEAD pointer

git checkout newbranch
 Changes HEAD to point to newbranch

Run git branch then git checkout to create and
start working from a new branch
 Shortcut: git checkout -b newbranch
$ git branch testing
$ git checkout testing
Images again stolen from http://progit.org/book/ which you should read because it’s good.
$ git commit
$ git checkout master
Images stolen from http://progit.org/book/
$ git commit


At this point, the branch history has diverged
We want to branch for new features and
merge them back into the master branch
 This makes your life infinitely easier
Images once again stolen from http://progit.org/book/

git config --global merge.tool toolname
 Sets the merge tool for your OS user


A merge tool allows you to fix any conflicts
that arise from merging two branches
Google will give you a list of merge tools
 I use p4merge, it’s hard to go wrong just choosing
a random merge tool and using it

git mergetool
 Run this command if anything goes wrong with a
merge, it’ll allow you to fix things

git merge branchname
 Allows you to take another branch and merge its
changes into the currently checked out branch

Git has hyper-intelligent algorithms that
track your content, not your files
 If you move or rename a file and make changes to
it, it will still be detected as the same content
Image stolen from http://progit.org/book/
Image stolen from http://progit.org/book/
It’s relevant to see how the approach taken by Git
differs from that of terrible legacy systems like SVN
 Subversion doesn’t have real branches

 A branch is just a copy of your repository in a named folder
 SVN has no concept of branch history and therefore
cannot determine common ancestry to help with merging

Subversion doesn’t have real merging
 The svn merge command should be called svn diff-and-
apply-patch because that’s all it does
 “If a merge fails, run svn revert and do it by hand.”
 There is no way to tell whether a given set of changes
were the result of a merge or were just straight edits

git remote add reponame url
 Adds an external Git repository called name

git fetch reponame
 Fetches updated branches from reponame
including all updated data
▪ A remote branch shows up as reponame/branchname

Your local information about remote
repositories isn’t updated automatically
 You need to run git fetch periodically on your
remotes to get new branch/commit information
Image stolen from http://progit.org/book/

git push reponame branchname
 Adds a local branch to a remote Git repository
▪ You need to have write access to the remote repository
 Alternatively, merges your local branch into a
remote branch of the same name

git push reponame localbranch:remotebranch
 Explicit syntax for merging your changes from
localbranch into remotebranch

Always fetch and merge before you push
 Save yourself grief and error messages

git pull reponame branchname
 Fetches from reponame then merges the remote
branchname into your local branchname

git pull reponame localbranch:remotebranch
 Fetches from reponame then merges
reponame/remotebranch into localbranch

Syntactic sugar for fetching and merging
 Your workflow should be “git pull; git push”

git checkout -b branch remote/otherbranch
 Gives you a tracking branch that you can work on,
that starts where remote/otherbranch is

Tracking branches are local branches that
have a direct relationship to a remote branch
 You can just call git push/pull with no arguments
and it know which remote branch to change

git clone url
 Creates a new local git repository, creates new
tracking branches for each branch in the cloned
repository, creates and checks out an initial branch
that is forked from the remote’s active branch

Watch out if the remote repository doesn’t have
any commits yet (really common thing)
 Cloning will fail, you need to do git init, git remote
add origin url, create an initial commit with some
content, then run git push origin master
There’s some stuff I didn’t get to cover due to
time constraints
 Look up git stash, git submodule
 TortoiseGit is a Windows-only frontend for Git

 It’s a knockoff of TortoiseSVN and is really easy to use

Go read the Pro Git book because it’s short,
awesome, free, etc.
 Reading it will make you taller and more popular with
members of your preferred gender

Thanks for your time :)