Month: February 2013

I see a lot of forum threads and blog posts on “which is better – Subversion or Git? The real question should be “which is better for my workflow – SVN or Git?” I’ll attempt to help you sort it all out.

I’ve been handling version control on my projects with Subversion (or SVN, for short) for the past couple of years. I switched to using Git about 6 months ago and have been using it for version control in most new projects. Git and SVN both have their strengths and weaknesses. Which one you use should be based on the type of work you’re doing.

The way I used to handle version control was simple. Any time I made any serious updates to a project, I duplicated all of the files into a new folder and started working. That way, I still had a copy of the previous, stable version if I needed it. This is a ridiculous way to handle it, but it’s simple and it works, as long as you remember to duplicate the files before you begin working.

SVN is an older model of version control that handles this for you. The files live in a repository on a remote server and you create a local copy on your computer (or even multiple computers). “Updating” pulls the latest version down from the remote server and updates the files on your local version that are out of date. “Committing” pushes any local changes back to the remote server when you are done working.  You can revert back to an older version of a project (or even a single file) if you need to. It’s a great way of tracking a project without needing to retain duplicates of every file. It is designed purely for keeping track of project versions – If multiple people try to commit changes to the same files, a conflict occurs, which you must resolve, usually by comparing the 2 files and manually merging them. The goal is to keep your local and remote repos in sync at all times. I used Tortoise as my SVN interface and I’m fairly happy with it.

Git differs from SVN in a fundamental way. It’s a distributed version control system, meaning that it’s designed for multiple developers to work simultaneously on the same project. You again have a remote master repository and a local copy on your machine. The big difference is that when you “commit” a change, the changes are only made to your local repository. Then, when you have finished your work and the local version is stable, you “push” all of your local commits to the remote repository. The idea here is that you can have version control on your local machine and only merge your changes into the master when they are finished and stable.

Git also allows for “branching,” which means that there are different versions of the project stored in different branches. Master is the stable, production branch. Then you could create a branch for a new set of features that you are developing. This way, another developer can make bug fixes to the Master branch while you develop new features on the other one. Then you merge them together later. Git allows for many branches to be created, so different developers can work simultaneously without jeopardizing the stability of the Master repo. I’m not sure why, but Git is also generally faster than SVN for updates and commits. A lot of Git users do everything on the command line – I prefer a decent GUI, so I use SmartGit. Mac users tend to like SourceTree.

So, from my description, it would sound like Git is superior, but that isn’t completely true. It really depends on your project.

Git is designed for large projects with multiple developers working simultaneously. It handles this use case very well. The branches help prevent developers accidentally overwriting each other’s work, or creating instability in the master repository. The downside is that Git has a much steeper learning curve than SVN. I’ve been using it for months and I’m still getting the hang of it.

SVN, on the other hand, is really simple to work with, if you only have one or two people working on a project and the chances of creating repository conflicts are small. So, if you don’t need the “distributed” part of version control, SVN is a great choice.

Another thing to consider is the number of large binary files you will want to have version controlled. Binary files are non-text files, like videos and Flash source files (FLAs). Neither of these version control systems can keep track of changes in binary files, but SVN plays nice with large binary files – Git does not. Git purists argue that large binary files don’t belong in the repository, but I don’t necessarily agree. So, if you plan to have a lot of videos or Flash files in your repository, Git may not work for you. You can tell Git to ignore the large files, but that seems to defeat the purpose of version control.

Which do I prefer? Again, it depends. For my projects at work, Git has been great (unless I need to version a bunch of videos, Then, it stinks). I have a handful of personal projects that I prefer to handle with SVN. I have a USB flash drive on my keychain that contains the remote SVN repositories. So, no matter where I am or which computer I’m using, I can update from the USB drive and work, even if I have no internet access. You can do this with Git too, but since I’m the only developer on these projects, I don’t need the fancy-schmanciness of Git and SVN is less hassle.

Hopefully, this will help you decide which version control system will suit your workflow. If you want to set up a USB thumb drive repository, here are simple instructions for setting up a local SVN repository. Here are instructions for doing it with Git.