While you see a lot of posts about large teams switching from SVN to Git, I haven’t found many discussing the transition for a small team. Since we’re a team of two who just made the leap, I figured I’d comment on our experience.
Why We Originally Chose SVN
One of the many pieces of startup advice that echoes throughout the internet is “don’t optimize prematurely.” This applies all the way from the way you write your code to picking out your desk to choosing version control.
When we started GazeHawk and I had to build up our working environment, the obvious choices for us were SVN and Trac. I had used SVN extensively at both Mozilla and TripAdvisor. I’ve installed Trac before, used it at TripAdvisor, and really appreciate the simplicity and integration it has (nothing like checking in code with a “fixes #1234″ on the end and not having to mark anything in your bug tracker). I got the setup running in half an hour and we were good to go.
We’ve launched, released updates, and generally worked out the kinks in our revision control. Our needs are relatively minimal: we’re two developers working mostly on separate codebases. While it’s strange for a startup to have multiple repositories, our code is very clearly segmented into at least two parts (website and video processing), so.
Why Switch to Git?
Fast-forward 5 months: we’re still just 2 developers (soon to be 3), so our needs are fairly minimal. However, this seemed like a good time to make the switch for a few reasons:
- Fear: We’re self-hosting SVN on AWS…on our webdev server. Having all of our revision history and development code on one machine, especially one as potentially ethereal as AWS, is terrifying. Whether we move to GitHub or a hosted SVN option, it was definitely time for a change.
- GitHub: GitHub has a *ton* of social proof behind it. People absolutely love that place. It handles keys very well, and it’s easy to use while still offering a ton of features. None of the hosted SVN options seem to have that many home-grown evangelists behind them.
- Branching: I had just created my first branch in the GazeHawk SVN repo. I had horrible flashbacks of late nights trying to merge an SVN branch back into trunk, coming to in the fetal position on the floor in a cold sweat. In less dramatic terms: SVN merging sucks.
- Obligatory “it’s the cool thing to do” comment: We don’t use Ruby on Rails, or Node.js, or any other trendy language/tool. We use what works best for our needs. I figured we may as well be one of the cool kids with something: version control seemed like a good choice.
A weekend of tinkering and everything is moved over to GitHub. svn2git makes the import easy (and leaves all my old tags in place). github-trac, while a little simplistic, at least lets me reference bugs in commit messages, meaning we can still integrate with Trac (the GitHub issue tracker is a little lightweight even for us). GitHub’s docs are perfect and make the move from SVN really comfortable.
The big question is, with neither of us having much exposure to Git (I used it very superficially for a school project), how was the transition for us? At its simplest, ignoring branching, tagging, and when using GitHub as a central server, Git is merely SVN with one additional level. In SVN you check code in/out from a central server, whereas in Git you check code in/out for a local repository unique to your working copy, and push/pull from a central server at your liesure. Once we both understood this concept, and had a list of Git equivalents to SVN commands, we were 95% as effect with our current 2-person workflow.
I’ve just gotten into branching and it seems easier to use (at least there’s less typing involved in creating/switching between them). Merging remains to be seen, but I imagine it’s at least as good as SVN, especially given all I’ve read about it. Deploying code is also about the same: a few changes to my bash script and all is well.
Even ignoring the time Git will (theoretically) save us in the long run, I’m confident the switch was a good move now. It didn’t cause much downtime for the two of us, and it’s a lot easier to switch while you’re small and don’t have weird version control rot. I’d definitely recommend at least looking into Git (creating a test repo, poking around, etc.). Don’t bother optimizing your version control too soon, but if you have some sore-points with SVN, or are expanding your team and don’t want SVN to become another technical debt in the back of your mind, it may be worth switching.