Hey all, Here is a collection of links and tips I think would be useful for using git with our project, along with a summary by me and some reasons that I prefer git to SVN. Git allows for more choice when working than subversion does. The typical subversion workflow includes checking out the repo, making changes, and then committing back directly to the same branch. If any mistakes were made or if your connectivity is down, you're SOL. Git allows for multiple different styles of workflows, though I foresee us using one very similar to the generic centralized SVN workflow should we chose to use git. With git, there's a few extra steps in between editing code and having it be in the repository. Git allows you to have something called an index, where you can stage individual bits of changes that you'd like to commit. This is extremely handy when you've made several edits to multiple files simultaneously, but only want to commit code belonging to a single feature. Once you're ready, you can commit to your local repo. Every git clone is a self contained repository that has everything needed to function. In essence, when you clone a repo from somewhere else, you've got roughly all of the features SVN has but you can use them all locally, without a network connection. Git adds another step called pushing where you can take your changes and throw them up on the server en mass. This means it's usually better to do many smaller commits locally, and then push batches up to someone else when you're ready. This feature, along with the ability for other people to pluck changes remotely from other repos, called pulling, allows for several interesting workflows to emerge. Another killer feature is the ability to quickly and extremely cheaply create topic branches. Essentially you're able to fork your repository in a branch in one command and then do exploratory edits in that branch. If you don't like what comes out of it, it's fairly trivial to delete the branch and then it's like nothing ever happened. Due to this, most git users like to keep a master branch that contains the canonical code and then do most of their edits in topic branches locally, merging the branches only when they're ready to make a newer release. Using the ability to pull/push and the ability to create cheap, easily mergible branches allows for another feature I enjoy, where maybe I'm not ready to push my changes to a central server and I'd like Chris to take a look at them. I can ask him to pull from me temporarily and try out the changes locally. He can then make modifications to that branch and then send them back to me and if I like them I can then have them put on the central server. http://progit.org/book/ch5-1.html -- This link contains several popular workflows. I foresee us somewhere between the centralized and the integration manager workflow. We should have a centralized repository into which we feed the code to a testing harness, most likely Jenkins. Chris will handle the integration of code into a blessed repository and the other developers will feed their code into a staging repository, where if everything checks out, should be merged by Chris into the 'official' repository. Jenkins also has robust support for git: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin Utilizing the cheap branching feature I discussed earlier, we can set it up such that when you push your code to jenkins for testing, you don't actually push it into the 'master' branch. You push it in its topic branch and jenkins will reject it if it does not merge cleanly with the master branch, as well as if it does not pass tests. That way you can keep the master branch containing only with tested, working code. There are also several plugins for git to integrate into IDEs and editors to ease the transition. However, I prefer to get down and dirty on the command line and be rather meticulous about what I checkin and how. I'm weird like that. I'm quite positive I was completely ineloquent in explaining this and my vision so feel free to berate me mercilessly and ask questions for clarification. I've included a wealth of informational links and a video at the bottom. http://git-scm.com/ -- Official website. http://progit.org/ -- Git book released for free online, very comprehensive and full of tasty graphs. http://www.youtube.com/watch?v=8dhZ9BXQgc4 -- Randal Schwartz talking for an hour about git, explaining it in detail. http://gitref.org/ -- GitRef, awesome quick git reference. http://www.kernel.org/pub/software/scm/git/docs/everyday.html -- Everyday Git -- 20 git commands that will do 95% of what you need to do everyday. http://git-scm.com/course/svn.html -- Git tutorial for SVN users. http://gitready.com/ -- collection of git tips of varying levels of diffifculty