Embracing Git for version control

First published: Read time: 4 mins

For many years I’ve been using Subversion (SVN) as my version control of choice. It’s been a part of my deployment process, all of my work is in Subversion, even the small demos I’ve created are in a repository. It’s a good feeling to know that if your laptop dies (or is stolen), all your work is backed up on a remote server.

Recently I’ve heard many developers raving about Git, and I’ve looked at libraries and code snippets that are using it, so I thought I’d check it out and see what all the fuss is about. After a couple of hours reading up and watching a few tutorials I’m genuinely excited about using it in future projects. It really is that good! So, what’s so good about it then you may ask? Well here are a few points that stood out for me:

  • Easy to install and start using (Windows has a simple installer)
  • Distributed version control, so no need for a central server
  • Runs on your local machine, no need to connected to the internet to commit(!)
  • Very clean, it only creates one git directory for the whole repository (no hidden .svn’s everywhere)
  • Incredibly easy to branch and merge your code (this is a big plus!)
  • It’s simple to use Git with SVN, no need to abandon your SVN repositories. Git can pull & push directly into an existing SVN repository!

I’d heard developers saying how easy it was to branch and merge your code using Git, I assumed they were exaggerating. But no, it really is simple:

1
2
3
4
5
6
7
8

#create a new branch in my repository
git branch my_new_branch

#move to the new branch for commits etc
git checkout my_new_branch

#finished with the branch, so lets merge it back into master
git merge my_new_branch

One of the most amazing parts of Git that blew me away: when you jump between branches it automatically updates your file structure accordingly! So lets say you have a new set of files in a new branch, and you need to jump back to master (trunk) to make some changes. Simply run ‘git checkout master’, the new branch files will be ‘removed’ and stored away until you are back on the new branch where they were added. Amazing!

The feature that really sold Git to me was the stash command. So many times I’ve been working on a project and got half way through some changes, only to have to fix a bug in the original version. So you copy the modified files somewhere, undo all your changes, fix the bug, copy the files over and start where you left off. Not fun! Git and the stash command come to the rescue:

1
2
3
4
5
6

#store your current changes in a 'clipboard' so they can be seen again later
git stash

#you are now working on the unmodified version of the branch
#after you've fixed the issue, start from where you left off by applying the stash
git stash apply

Another huge advantage Git has is how simple it is to share code between developers. It only takes a couple of commands to clone another repository. Once you have a local copy (clone), you can change whatever you like. Make the project better (or break it horribly, it’s up to you). For an example of how powerful social coding is take a look at Github. The 3D JavaScript library three.js for example has over 4000 people watching and 400+ people have forked (cloned) the repository. If your version adds a cool new feature or fixes a bug, it can easily be merged back into the original project!

If you are interested in learning how to use Git there are some superb resources available. For people who like screencasts I highly recommend watching the one created by Peepcode. It’s only $9 (US), 1 hour-long and will get you up and running with Git in no time at all! Here are some other resources I found useful:

Right, I’m off to start committing to a repository while travelling on a train to work when I don’t have an internet connection (warm fuzzy feeling enabled)!

Webmentions