1. Distributed Version Control

2. Image stolen from http://progit.org/book/ which is really good, go read it.http://progit.org/book/  Old-school version control like RCS

3. Image stolen from http://progit.org/book/ which is really good, go read it.http://progit.org/book/  This is how Subversion works

4. Image stolen from http://progit.org/book/ which is really good, go read it.http://progit.org/book/  This is how Git works

5.  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

6.  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/ http://code.google.com/p/msysgit/  Mac: use the OS X installer  http://code.google.com/p/git-osx-installer/ http://code.google.com/p/git-osx-installer/

7.  Read Pro Git, it’s excellent and free  http://progit.org/book/ 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/.http://progit.org/book/

8.  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 “you@place.tld”  --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

9.  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

10. Image stolen from http://progit.org/book/ which is really good, go read it.http://progit.org/book/

11.  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

12.  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.http://progit.org/book/

13.  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

14.  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 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

15.  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!http://progit.org/book/

17.  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

19.  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

20. Images again stolen from http://progit.org/book/ which you should read because it’s good.http://progit.org/book/ $ git branch testing $ git checkout testing

21. $ git commit $ git checkout master Images stolen from http://progit.org/book/http://progit.org/book/

22.  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 $ git commit Images once again stolen from http://progit.org/book/http://progit.org/book/

23.  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

24.  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

25. Image stolen from http://progit.org/book/http://progit.org/book/

26. Image stolen from http://progit.org/book/http://progit.org/book/

27.  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

28.  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

29. Image stolen from http://progit.org/book/http://progit.org/book/

30.  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

31.  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”

32.  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

33.  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

34.  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 :)