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.
The Transition
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.
Conclusion
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.
Having been down this path before, I have to warn you: It gets worse before it gets better. I originally hated git, but that’s because I was entrenched in my svn ways. Once I managed to change my way of thinking, things got much easier.
Here’s where I was a while back: http://blog.aisleten.com/2008/11/23/git-the-fsck-out/
Now, I’m a total convert.
A few final bits of advice:
1) Don’t mess with rebase for a while. You technically don’t need it. It’s handy, but give yourself some time to learn the rest before tackling it.
2) Think long and hard before doing a “push -f” Most likely, you’re about to cause yourself (and the other developers) a lot of grief.
I love Git for the most part! I haven’t had to rebase or anything yet.
We have found that this branching model is pretty easy to wrap your head around and work with. Not that you have to stick to it religiously, but it’s a great policy to start from.
@Micah What’s `push -f`?
push -f will force a push to the server, it can cause loss of commits… so sometimes it will screw up your version history or you may break someone else’s push because there is no version history left intact for git to use to figure out how to merge…
if you have read through the book git pro you can ignore the rest of this comment
A little on the merging, git will if it can always merge in the simplest way possible, for example if you have a local repo of your code and you branch it once and never touch the main brach and you merge it will simply “rewind” your changes back to the point that the repo was at when you branched the “fast-forward” your changes back onto the repo. If you make changes to your main branch (like a hotfix) git will rewind both branches then fast-forward them both assuming there are no problems that it is not able to resolve if there are problems like that it will simply mark them and ask you to use what ever diff tool to fix them that you have told it to use.
All that said the reason that push -f could cause problems is that git does not have the history available so that it can rewind during merges
good luck,
eric
Use Mercurial; its simpler, easier, and is a lot more straight foreward, also a lot easier to manage the repo
I suggest using bitbucket if u do choose mecurial; heck, it might even work for git
And bitbucket’s issue tracker being slightly more complete than github’s one might even help you get rid of github-trac…
Been thinking about doing it for a number of my project that I have currently on SVN, and on my own server.
Any reason you picked git over say something like mercurial?
Pingback: How to Switch From SVN to GitHub for Small Teams
In moving from self-hosted SVN to github-hosted Git did you have any concerns about putting your code in the hands of a third-party(albeit competent) provider?
I have horrible visions of my repo accidentally being set to “public” and someone cloning my entire startup’s codebase – to be forever hosted on the interwebs somewhere.
Did you look at self-hosted Git?
This article seems a bit premature, and lightweight.
1) Tell us how it went after six months, not after six days.
2) “Merging remains to be seen, but I imagine it’s at least as good as SVN” – is an extraordinary comment since apparently it was the branching/merging workflow that frightened you away from Svn. Yet you didn’t actually examine what you’d have to do in git in the same situations?? Doesn’t add up.
3) “I figured we may as well be one of the cool kids with something: version control seemed like a good choice” – Um, no. Version control isn’t turf you play “cool” games on. You pick something mature, reliable, and where your skills are.
4) “We’re self-hosting SVN on AWS…on our webdev server” – why is that a problem? You don’t take backups?
GitX.app and speed are my reasons to use Git.
However, don’t believe that Git makes merging magically work. If you have conflicts, you will have to resolve them, no matter what system you use.
I did have fetal-position merges even with Git.
Pingback: links for 2010-11-04 — Business Developer Talk
“Merging remains to be seen…”
This is technically not true. If you push/pull to/from a remote repository, you’re merging branches (most likely your local master with remote master). It doesn’t remain to be seen, you’re already doing it!
Pingback: Favorite Articles of the Week | MediaLeaf Blog
BCS CMSG has a free event on experiences with Git in the Enterprise on 25 Nov 2010 in London if anyone is interested:
http://www.bcs-cmsg.org.uk/events/2010-11-25.html
Dan North (originator of BDD among other things) will be presenting experiences from his new company DRW in migrating SVN to Git.
Pingback: Switching from SVN to GIT | Free practice test , mock test, driving test, interview questions
We’re a team of three who commit code hourly to our SVN repo. We use WEBSVN and pull feeds from WEBSVN into OpenAtrium so that they display in each projects dashboard. We don’t find ourselves having to branch and merge often. Our repo is on our development/staging server which is backed up daily.
One of us has been pushing for a change to GIT for ages and I’ve been reluctant or not interested. From my understanding GIT is a system that would suit projects that have a large number of people committing code with each of these people being loosely connected ie: little communication. GIT appears to suit individuals that randomly contribute to a project and SVN seems more geared for (small) teams who work closely together with open communication channels.
SVN can be clunky. I found a solution to it’s clunkiness is getting to understand the most common commands well. We also have a few useful bash aliases setup to make the ride less bumpy. I’ll post them should they be of service to anyone.
## SVN TOOLBOX
#checkout a project from our repo without typing the entire url
#provide project path from root of repo and destination directory
#example: svnco ourproject/trunk/5x local.ourproject.com
svnco () { svn co svn+ssh://67.54.23.22/home/repos/$1 $2; }
#remove all .svn folders. The project will no longer be under version control
removesvn () { find . -name .svn -print0 | xargs -0 rm -rf; }
# bash function to add all new files and directories in a working copy to repo
# this funtion is used when you have many ? when running svn stat
svnadd () { svn stat | grep "^?" | awk '{print $2}' | xargs svn add; }
# the reverse of the previous command. usually used to get rid of old svn log files
svndelete () { svn stat | grep "^!" | awk '{print $2}' | xargs svn delete; }
# svn diff with color - in Ubuntu run: sudo apt-get install colordiff
svndiff () { svn diff "${@}" | colordiff; }
Pingback: Tools Of The Trade : Brian Krausz from GazeHawk