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.
C. Michael Pilato
Appreciated the article. Nice to see a balanced view of this seemingly inflammatory topic.
I do take issue with one statement, though:
“Neither of these version control systems can keep track of changes in binary files, …”
Out of curiosity, how do you define “keep track of”? I ask because, technically speaking, Subversion’s repository *only* tracks binary files and the differences between them. In other words, the Subversion repository doesn’t care whether a file is human-readable or not — its differencing engine is a binary delta algorithm, not a contextual diff engine. If you change one byte in a multi-gigabyte binary file, Subversion needs only to store that one byte (plus a little bit of metadata) for the new version of your file.
Andy
I didn’t know that SVN worked that way. Feel free to correct me if I’m wrong, but I believe that GIT can NOT track the differences in binary files. It can tell that the file has changed, but it simply replaces the older file with the new one. This may be why Git sucks for large binaries, but SVN handles them with ease. Thanks for the clarification.
Todd Lyon
I think the complexity of GIT drastically slows down the standard development life cycle. GIT is awesome for managing teams of developers on complex systems with multiple environments etc … . But for a small dev team just trying to develop, test, and track changes, it is a hindrance that more often than not slows everyone down and gets in the way. Yes, it is the safer option for preventing conflicts, keeping environments perfectly in synch etc … , but that safety comes at an extreme cost in terms of productivity and for a small shop trying to develop ….. the cost benefit analysis results in choosing something other than GIT, and SVN is a good choice.