3 Reasons to Switch to Git from Subversion

Dozens of articles outline the detailed technical reasons Git is better than Subversion, but if you’re like me, you don’t necessarily care about minor speed differences, the elegance of back-end algorithms, or all of the hardcore features that you may only ever use once.  You want to see clear, major differences in your day-to-day interaction with software before you switch to something new.  After several weeks of trials, Git seems to offer major improvements over Subversion.  These are my reasons for jumping on the Git bandwagon.

Let’s start with a few assumptions for the scenarios we’ll walk through:

  • you’re one of many developers for a project
  • all changes going into production must first be peer-reviewed
  • you all use simple GUI text editors like TextMate or an equivalent
  • you have 4 features that you’re working that are due soon

Let’s get to work.

Endless, Easy, Non-File-System-Based, Local Branches

You’d like to work on each of your 4 features A, B, C, and D independently and somewhat in parallel, though B looks like a quick win.  Let’s compare the branching features offered by both Git and Subversion side-by-side as we get going:

Task Git Subversion
1. Get a copy of the project on your local machine. git clone /srv/repos /local/copy svn checkout /srv/repos /local/copy
2. Create branches A-D to represent the features you’re working on. git checkout -b A
git checkout -b B
git checkout -b C
git checkout -b D
svn copy /srv/repos/trunk /srv/repos/branches/A; svn checkout /srv/repos/branches/A /local/copy/branches/Asvn copy /srv/repos/trunk /srv/path/repos/branches/B; svn checkout /srv/repos/branches/B /local/copy/branches/B

svn copy /srv/repos/trunk /srv/path/repos/branches/C; svn checkout /srv/repos/branches/C /local/copy/branches/C

svn copy /srv/repos/trunk /srv/path/repos/branches/D; svn checkout /srv/repos/branches/D /local/copy/branches/D

3. Feature B is very simple and you want to knock it out and get it into production ASAP. git checkout B
[work in editor]
git commit -a[peer review]
git format-patch
git send-email [options will vary]
[peer gives you “thumbs up”]

git checkout master
git merge B
git push

[open text editor for branch B]
[work in editor]
svn commit[peer review]
[send email to peer with branch name]
[peer checks out your branch locally to review]
[peer gives you “thumbs up”]

cd /local/copy/trunk
svn merge /local/copy/branches/B .
svn commit

4. Get rid of unnecessary branch B. git branch -d B svn delete /srv/repos/branches/B
svn update

Note the key advantages Git offered in each step:

  1. Git creates a full repository with this command.  With Subversion, you’re just checking out the files in the repository.
  2. With each branch, no new files are created in the project file hierarchy on your system.  Since you have a full local repository, Git creates the files you need on the fly by processing the recorded changes.  With Subversion, you have to create every branch remotely on the server.  This can get messy depending on the size of your team.  If you decide to control branching to keep things clean, you forfeit the power branching offers.
  3. With Git, we only push our work to the server AFTER collaboration (more below).  With Subversion, it all hits the server.
  4. Again, no file system work.  Since we’re using a local repository, we let Git handle the details of removing the branch.  With Subversion, you still have the old copy until you update.  You either have to clean up manually, or “update” to clean up local and remote copies.

In addition, try to do this scenario on your laptop while not connected to the Internet.  With Git, no issues, the repository is local; however, with Subversion, you’re out of luck.  Your new branches will have to wait. The advantages of Git for branching are clear in this simple branching scenario.  Let’s continue to look at our scenario with non-trivial features A, C, and D that we’re working on.

Stashing Temporary Work

You start working on A and you’re about 100 lines of code into it when you get stumped on a math function.  The math wiz on your team is out for the day and you’d rather not continue until you consult him.  You’ve got some ideas for C, so you decide shift gears and get started.

Task Git Subversion
1. Switch to branch A, write 100 lines of code git checkout A [open text editor for branch A]
2. Switch to branch C  while waiting on a co-worker’s advise for A git stash
git checkout C
[close text editor for branch A]
[open text editor for branch C]
3. Work on C for a while, get advise from co-worker and resume work on A git stash
git checkout A
git stash list
git stash apply [stash name]
[close text editor for branch C]
[open text editor for branch A]

At a glance, you might get the impression that Subversion is simpler, and you’re probably right.  However, this is one case where simple may not be what you’re looking for.  Let’s look at each step:

  1. The key thing to note in this and every step is how we switch between branches.  In Git, the repository handles this. With Subversion, you’re literally just working on a separate set of files.  Ultimately, it’s up to you to manage retrieving and editing these files.  If you’re using TextMate, you’ll probably save a TextMate project file every time you branch simply to give you quick access to the branch.  If you branch a lot, this quickly becomes annoying, time consuming, and non-productive.  With Git, when you checkout a separate branch, it “magically” changes all of the files on your file system for you.  That means 1 project file is all you ever need.  Git handles the rest.
  2. Git will “float” uncommitted changes.  This means that if simply did a “git checkout C,” you’d bring with you all of the uncommitted work you did for A.  However, you don’t want to commit A because it’s not in a good working state.  Instead, you “stash” your work.  Stash is like a work in process commit.  Using it will tuck away your WIP changes without a formal commit, which allows you to change to C without “floating” any of your A changes.  The Subversion method is simpler, but you could potentially end up with several half-baked branches and no record of when you abandoned them.  Git’s stash allows you to list all stashes, and even write a message when you stash.  It is far more powerful in this scenario.
  3. Same as 2, but shows the “git stash list” feature.

So now we can work smoothly between multiple branches without worry of the consequences of interruption.  Git thus far has shown immense strength in two key areas, but let’s revisit collaboration to seal the deal.

Collaboration Before Public Commits

It’s now weeks later and you’re working on D.  After some round table discussions with the team, you all agree that D may not be the best approach.  A co-worker starts working on his own branch E and a few days later wants to review it with you.

Task Git Subversion
1. Review co-workers suggested changes in his branch E [check your email for patch]
[review patch]
svn checkout /srv/repos/branches/E /local/copy/branches/E
[open text editor for branch E]
svn log [to find changes]
svn diff [to view changes]
[review branch]
2. Agree that E is better and destroy your branch D git branch -D D svn delete /srv/repos/branches/D
svn update

Git offers power by putting collaboration up front before commits are public for all to see.  Consider in each step:

  1. Git has a nice feature to create “patches.”  They are simply changes to code, very similar to a diff.  The idea is that you create patches from commits you’ve only made on your local copy of the repository.  When your co-worker sent you the patch for E, no one else on the team had to see his commit logs, branches, etc., in the public repository because they never existed there.  You are collaborating about E via emailed patches.  With Subversion, it’s all on the server, all the time.
  2. With Git, deleting an abandoned branch is simple and clean.  The work done in D will never be seen by the public, i.e., your team.  You’ve spared the team clutter both in the logs and on their file systems.  With Subversion, the clean up is on you.  Should you forget to delete D, it’s has the potential to get used and that could be bad.  Conversely, someone else may have quietly checked out D and been working on something.  When you delete it from the public repository, their commit will surely fail.

Conclusion

There are literally hundreds of features for both Git and Subversion.  While you may have detailed reasons to choose one over the other, I think these 3 high level reasons are strongly convincing in favor of Git.  If you have differing opinions, I’d love to hear them.

67 thoughts on “3 Reasons to Switch to Git from Subversion

  1. I’d like to take issue with the second assumption:

    “you all use simple GUI text editors like TextMate or an equivalent”

    I don’t think this assumption holds true or has held true for any thing I’ve worked on in the past 10 years or so.

    From the rest of the article though — that seems to be the lynch pin to the whole idea though, so uh. “that’s nice.”

  2. @liam,

    Well, I couldn’t cover all possible setups, so I picked the one that reflects how I work (and have worked for the last 10 years). I understand that various IDEs may make things easier, but I wanted to take them out of the equation, i.e., I’m comparing svn and git, not git and some IDE that nicely supports svn.

  3. You seem to be unfamiliar with the svn switch command; either that or you are intentionally increasing the steps needed for subversion.

  4. Hi Mark. Thanks for the very interesting comparison. This is the first article I have read about git, and I was particularly interested to learn about stashing and “float”ing uncommited work. Sounds interesting, although I speculate that git may in fact work better for a gatekeeper scenario like the kernel than for many business environments, which may be more structured from the point of view of making formal branches and tags.

    Anyhow, one note I would like to make is that one can simply do “svn cp ./trunk/ ./branch/thisrelease; svn commit” to make a branch and commit it using svn. However the example you give is recommended at http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html#svn.branchmerge.using.create. Note, however, that in the ensuing discussion about “Cheap Copies” on the referenced page, that Subversion uses a “hard link” type methodology to ensure that branches are in fact simply pointers to the original data, until they are changed.

    I’ll certainly give git a go. Many thanks. Rory

  5. @Joe,

    I’m familiar with it, but always found it cumbersome, e.g., tracking the full URLs of remote branches, etc., each time you want to switch. Though I’ll be honest though, I never gave it much use so there may be a much cleaner way to use it. Thanks for the tip, I’ll check out the docs.

  6. I don’t see a real difference between git and svn. I rarely touch the command line. I use RapidSVN, and it simplifies the vast majority of my every day work.

    The source code repository is also a small part of the development process. I’ve used Trac with subversion (with a few minor modifications), and it works great. That whole process of peer review is a lot simpler with Trac. An integrated development process is more important than the number of keyboard strokes I use on the command line.

  7. @G R,

    I also use SVN+Trac and I agree, it’s good. However, I hope my article didn’t come off as highlighting keystrokes. I intended to highlight the process from the developer’s perspective. Trac is great once you’ve decided to commit. It’s everything before that step where I see Git providing a lot of benefit. I use stashing, floating, and pre-commit patch review a lot. svn just doesn’t work as well in these instances. I do agree though, in combination with the right software, svn can be highly functional.

  8. “you all use simple GUI text editors like TextMate or an equivalent”

    So what about the big IDE’s makers? Are any git plugins available for say IntelliJ or Eclipse or NetBeans? The SVN plugins for these IDE’s are a breeze to work with.

  9. I develop on Windows, and use Tortoise to integrate with SVN. Tortoise makes managing an SVN project quite easy – you use the explorer interface. It seems to me that we’re really talking about an interface comparison here, not a discussion of why Git would be better than SVN in a technical sense. It doesn’t seem to improve on branch to trunk merging, for example: The basic procedure is the same for both. Creating branches is the same procedure, etc. The only thing that changes is the length of the command.

    So my question is are there any real, fundamental differences between Git and SVN that can’t be overcome by the right wrapping interface?

  10. @Lee,

    I’m not sure. I don’t use IDEs personally. As I mentioned to liam above though, in this article I really only wanted to compare svn to git and not the software they integrate with. You’re probably right to some degree though. Older, more mature software usually has better 3rd party integration.

  11. @steven,

    You’re right, the basic concepts are very similar for both if you want them to be. I think where Git begins to define itself is when you consider the power of having the repository locally to branch indefinitely, the ability to float uncommitted edits to other branches, the ability to stash interim work, and the ability to solve the various other issues that many developers run into. Things like Tortoise may close some of these gaps, but I think the thing to highlight is that those items are positives for Tortoise, not Subversion from a stand-alone perspective.

  12. “With Git, we only push our work to the server AFTER collaboration (more below). With Subversion, it all hits the server.”

    Does this mean that the only copy of my changes is held locally until after collaboration? What if my hard drive dies before I get the thumbs up? Or what if I get an idea at home and want to check out the branch I was working on to my home machine? Does stash save a copy to the server, flagged as unfinished? I like the idea of making branching easier, but only if they aren’t locked down to individual hard drives.

  13. Why are you comparing Git to Subversion? Git is distributed version control — Subversion is not. Isn’t that really the biggest difference? Perhaps you ought to consider Mercurial.

  14. @Matthew,

    I think there are several options to deal with this, but two jump out at me. 1. set up Git like you would Subversion. It works and everything will be on the server, but you kind of lose the power of Git. 2. (what I do) have a network backup. This is good for far more than code as you can ensure all of those Excel and PowerPoint docs you have don’t get lost.

    I think the local branching is different from the usual branching you get with SVN, et al. When I work, sometimes I’ll make a quick branch just to try something out or capture a thought I have. Hours later, I may decide that some of my ideas were bad and discard those branches. At the end of the day, if I must commit, I can merge all of the relevant branches and push them remotely … to a remote branch if I want. I think the power Git offers is between the time you sit down and the time you go home. You have maximum flexibility and aren’t constrained by the setup on the server.

  15. @astrochicken,

    I’ve never used Mercurial, so I have no reference point. I came from SVN (was/is heavily used in the Rails community) and moved to Git (is/becoming more heavily used in the Rails community). That’s why I picked them.

  16. I use SVN at my work for production code (not open source work), and we exclusively use it via command-line in linux, so I’m familiar with a lot of these trade-offs. Some of the large differences optimize for a certain development model / style which suits OSS quite well, but I argue isn’t optimal for a corporate environment.

    For one, you don’t actually push branch changes to the server when doing branch work (based on your description above). To me that’s dangerous. If I’m sitting doing 90% of my coding with a high-speed link to the server, I want to push as often as I can to back this stuff up. I want all my branch history to be available at the server and I don’t want it deleted.

    Your ‘collaboration before public commits’ is very misleading. Your steps for svn are very poor to have a co-worker review a diff based off a branch. We personally integrate svn into a peer reviewing tool like ‘Review Board’ from VMware. One simple command line tool with no options automatically creates and posts a diff to a slick web UI for easy viewing by anyone. No one actually checks out a branch to peer-review a diff – that’s just not how I’ve ever seen it done in the real world. Emailing diffs around (which you do in your example with git) is also not cool. I want to post diffs for peer review with full comments to a database system that keeps the history. SVN allows me to do this just as easily as with git using another tool. Also, you point out that git allows you to create easy patches. ‘svn diff’ does exactly the same thing.

    I think the only two real wins git has over svn are the stashing and easy branching ability based on the fact you have the full repo on disk, and easier merging. As I pointed out above, the development methodology of the first advantage doesn’t suit everyone, particularly those who don’t care hitting the server often. The merging, which you hardly touched on, is huge. That is svn’s achilles heel.

  17. @Justin,

    For your first point, see my note to Matthew above. I’m not sure “backups” are a good reason as there are many solutions to that problem. For your second point, I agree, integration with other software is key, but I was only looking at this from a pure svn to git comparison as I couldn’t hope to possibly consider all the potential ways to set either up with additional software. Lastly, I agree I glossed over the merge advantages and you’re right, it is a big win.

  18. Also, in some ways hitting the server is a feature, because it’s a form of backup as well as passive monitoring/communication.
    In other words, if a developer goes loner and then his machine crashes, in the git model its more likely to lose data because it’s all probably confined to his machine. And further, it’s harder for interested parties to follow ongoing development because the dev has to explicitly send them updates, which is distracting to the dev.

  19. @Ethan,

    See my reply to Matthew. Git does not preclude talking to the server frequenly. It just enables a better workflow between the times you do.

  20. FYI, I have several svn repositories that I regularly use at work. Most of these are svn+TRAC, while some are just standalone svn. I’ve been using git-svn for almost a year now, which allows me to create svn checkouts from a svn backend. This is a fantastic way to have your cake and eat it too. You can read up on how to do this here: http://flavio.castelli.name/howto_use_git_with_svn

    I regularly like to checkout copies to my laptop and take them with me. Work on it offline and when I get back to work check all my changes back in. Highly recommended!

  21. IntelliJ does have a Git plugin. I have not used it yet, but it has recently been updated. Looking forward to trying out Git.

  22. The local branch example looks like something that an IDE or at least a good merge tool would do better than a Version Control system. Maybe it looks good for you to use git for that precisely because you don’t use any such thing.
    I actually find it difficult to understand your concept of peer review over local modifications. Wouldn’t the peer be on a different environment by definition, or do you all share the same compy all the time? If the latter, how do you manage parallel work among a team?
    What many pointed out about committing as frequently as possible isn’t just a matter of having your work saved, but historized. Such history would be lost even if you had a backup, and if you happen to forget why you did something or rolled something back, and it was all local, you’ll be at a loss.

  23. @Felipe,

    Imagine we’re both working on branch X of a project. We set up X as a remote branch on the server. We both check it out and begin work. With Subversion, we start to lose flexibility at this point. With Git, my remote master is branch X. My local master is a checked out version of X. I create branches A and B, that you’ll never see or care about. I work on A and commit 25 times locally, each with a message. I work on B, commit 5 times, each with a message. Neither are on the server yet. At some point, I merge A into my master and pull down any changes you’ve made on X. You have made some and conflicts exist, which I resolve and merge. I then push my work to the server, X.

    At this point, we can see each other’s relevant work. You see all 25 of my A commits and messages. You have my history. You can’t see branch B, but that’s good. I may decide your work is better than B. I may decide I don’t like B at all. If I do decide it’s worthwhile, I go through the same drill and you get my history. Maybe B is in direct conflict with your commits. Rather than overwrite your work, I send you an email patch for review. We both decide yours is better and I simply delete B locally.

  24. I don’t see how got any advantage over svn in the review department. One could mail someone the result of “svn diff” for review and have exactly the same result as “git format-patch”. Because lets be realistic a moment, in git nothing is really commited until it’s pushed to a central repository.

  25. I’ll add a fourth, which is the “killer feature” for me and my current workflow:

    Git allows working from more than one system at once without requiring a constant server connection. When I’m on the go and want to make changes to my code from my laptop, I can make commits, I’ve got access to the full history, etc. All that’s required is a pull from my desktop before I leave my office, and I’ve got a shell script that pulls the repositories for all my projects at once.

    With something like SVN, this kind of thing was a major pain, as I’d either have to work just with my local copy on the laptop (leading to poorly tracked mega-commits), or copy the whole file system structure of the repository to the laptop, which quickly gets you into desynchronised territory. Add another developer and you’re instantly dead with that kind of system.

  26. Being through a few over a long time, pvcs, soucesafe, cvs, svn and git. git is the business. Would recommend. The writin’s is on the wall for subversion.

    J

  27. I am confused. In this example:
    [open text editor for branch B]
    [work in editor]
    svn commit

    [peer review]
    [send email to peer with branch name]
    [peer checks out your branch locally to review]
    [peer gives you “thumbs up”]

    cd /local/copy/trunk
    svn merge /local/copy/branches/B .
    svn commit

    Does the Git user not need to perform these steps (or their equivalent)?
    [open text editor for branch B]
    [peer checks out your branch locally to review]

  28. First, I just want to say that Git and DVCS in general is something that interests me, I have worked with CVS and SVN for the past 6 years. I do see a problem with your local branch workflow, and that is the lack of constant team collaboration. One particular thing you said in your reply to Felipe helped me to realize the problem I’m having with your post.

    “I create branches A and B, that you’ll never see or care about.”

    If we are both working on branch X, we’re probably working different parts of feature X. As an example lets say that you are working on the model layer for feature X and I’m working on the presentation layer. What would be more useful to me? Getting 2000 new lines of code for the model complete with several interfaces at the end of the day after you closed out branches A and B and finally merged back to X. Or, getting the stubs and interfaces through out the day as you finished each of them. Whether Git makes it easy to frequently communicate with the server or not, committing work the way you describe doesn’t promote a team-friendly environment. Having your private commit history is useful, but it could have been more useful to have that history as it happened.

    I agree with astrochicken that comparing Subversion to Git is a tough and possible inappropriate comparison. Your post would have done better to compare the fundamental ideas of Distributed Version Control versus Version Control and in that comparison you could have referred to Git and SVN for examples. Also this post lends to the “better than what you use” hip-elitism that seems to come with Git and Rails. If you want to talk about why Git is awesome, do so without telling me why SVN sucks and I’ll probably listen to more things you have to say.

  29. “I’ll add a fourth, which is the “killer feature” for me and my current workflow:

    Git allows working from more than one system at once without requiring a constant server connection. When I’m on the go and want to make changes to my code from my laptop, I can make commits, I’ve got access to the full history, etc. All that’s required is a pull from my desktop before I leave my office, and I’ve got a shell script that pulls the repositories for all my projects at once.

    With something like SVN, this kind of thing was a major pain, as I’d either have to work just with my local copy on the laptop (leading to poorly tracked mega-commits), or copy the whole file system structure of the repository to the laptop, which quickly gets you into desynchronised territory. Add another developer and you’re instantly dead with that kind of system.”

    yeah we use Eclipse with SVN and we have no issues working in and out of the office on the go. We do it every single day.

  30. @Mike Cubes,

    I think you’re reading my times too literally. End of the day, end of the hour, end of every 10-minutes … doesn’t matter. My point is that in between pushes to the central server, you have more flexibility. You can choose to do none of this. I personally like it. If you want your team to see what you’re doing all the time, then push, push, push.

    And I don’t think this is an inappropriate comparison. The Rails community was largely tied to Subversion and now it’s moving to Git. Why wouldn’t I compare the two? There are lots of people like me who don’t care too much about either and want to know what they’re going to get if they take the time to make the switch. You can read that as hip-elitism if you’d like, but I’m just recounting my impressions. And I never said SVN sucks, I only said that it either takes longer, or doesn’t offer functionality that I’ve always wished I’d had and found workarounds for. These things I now find with Git.

  31. @Confused,

    No, you wouldn’t need separate text editor instances with Git. When you change branches, the files change too so one text editor instance would suffice. As pointed out by another commenter, svn switch somewhat offers this functionality, but not it’s quite the same. As for checking out, it depends. If you’re using the patch flow I mention, no, there is no “checkout”. If you’re pushing things through the central repository, yes, they are roughly the exact same.

  32. I think most of your readers tend to be stuck in their ways. They don’t see a reason to move over to git when their IDEs and other third-party applications make up for the shortcomings of SVN. Sure, every development environment I’ve ever worked in has used SVN and the people who made that decision all had a host of tricks and applications and scripts that made using SVN viable. They were all different and generally came with a tradeoff. But, in all of those environments, the decision makers couldn’t see why I suggested using git or hg rather than SVN. Essentially, any issue I could raise about SVN, they had a work-around to manage. Your readers are much the same way. Why use a tool that was designed to address the lessons learned when you could hack your current environment to make it work, more-or-less. I think this behavior is learned in college. Those CS students who’ve become so overwhelmingly adverse to “re-inventing the wheel” tend to favor hacking a bit of software that does something right rather than using a tool designed specifically for the purpose at hand.

    The point being, while I’m SURE there are plenty of solutions to the problems SVN has, maybe we should all start using git and develop some applications to make it cleaner and easier if for no other reason than I’d be able to walk into my next job and understand how their version control works rather than having to learn whatever series of hacks they’ve cobbled together. “Oh, it’s easy! See, what we do is run this script to create the appropriate sym-links and then check out the newest branch over here… *magic* and then just run ./cleanup.sh and you’re done!”

  33. I think this assumption is key:

    “you’re one of many developers for a project”

    This isn’t the same thing, necessarily, as the following:

    “you’re one of many developers for a website”

    In almost every situation where I have used svn, there has been either zero need for branches or the need for one was outweighed but the small number of changes. I completely agree that branch methodology for svn is not great, but for many smaller code repositories, this comes up so infrequently that it doesn’t even matter.

    We are trying to determine if git will be more useful than subversion for new website development. I like to use new software, but with only a couple of developers, I’m just not sure it’s suitable.

  34. @Ben,

    The beauty of Git is that you can have your small number of remote (server) branches. If I’m on your team, I may want to make a branch or stash locally that is only relevant for the next few minutes, hours, or whatever. For example, let’s say I want to toy with 2 wildly different style changes to the front page. Git makes this very easy/clean to do. I’ll only end up committing 1 or less remotely, but in the mean time the local branches help me, not you. They make me more productive, not your server or publicly committed code better. When I commit it remotely, it’ll end up in whatever branch you’ve determined. So it’s like having the same old server-client setup you get with SVN, but with the added power of a local repository too.

  35. You may call me old-fashioned, but I like CMVC more. The integration of Bugzilla with the Versioning system is awesome.

  36. Thanks for the clarification. I now understand your point about “local” branches and I agree that it’s an interesting feature.

    That said, answering a couple of comments regarding people being adverse of “re-inventing the wheel”, it’s important to understand that there’s a huge cost involved in changing. It’s not very effective to change your Version Control systems every 2 years because you’ll have a bunch of legacy servers with old projects to deal with. The great majority of a company’s departments won’t like to have to change tools ever so often either.

    So, speaking at least for myself, I prefer to see important advantages in changing what is known before doing so.

    As an anecdotal illustration (quite based on real life), company C has a corporate decision regarding what Version Control system to use, say, “CRP”. Department D thinks it’s a piece of crap and hinders them from working due to its many limitations. They know about another system, “HVN”, that addresses their needs much much better and they want to push it through the multiple layers of the corporation so it may replace “CRP”, or at least be accepted as an alternative in that department.

    It takes about 1-2 years to reach a situation where “HVN” is accepted as an alternative, even if by the time of delivery a project has to be replicated in “CRP”. During that process, many people even inside department D groaned about having to work with 2 tools at the same time, without understanding well why.

    Now, there’s a “new” Version Control system which claims to be even better than “HVN”. How likely do you think that the same company will accept to go through all that hassle again in so little time?

    For all that to happen, the old system has to be proven harmful or costly to the company’s business, or the new system has to prove to save a lot of money.

    All that to say that it’s very difficult to take a comparison like this and turn it into a change effort, specially if the system in place does the job. It certainly convinced me to look into it, tho : ) Although I personally love Eclipse and would find it hard to give up on the Subversive plug-in myself.

  37. @Ben – Seeing zero need for branches is a symptom of working with SVN. I forget where I read it, but someone last year made a comment that they didn’t understand how much they really wanted branches until they started using git. The fact is that even though SVN is a huge improvement over CVS, the pain of merging is such that SVN users develop an aversion to branching.

    I’ve been reading these kind of articles for the past couple years. The comments tend to be either of the defensive variety or the preaching-to-the-choir variety. There are always a few generally curious comments looking to learn more, but those are diminishing as the early adopter crowd has already all switched.

    Bottom line to you defensive SVN guys, please stop arguing out of ignorance. There are legitimate debates to be had between the various differences between DVCSs, but any and all of them are a generational leap beyond SVN. Don’t make up strawman arguments about how centralized is better in some cases, because centralized is a subset of distributed functionality–you can set up any workflow you want with a DVCS. A proper merge model (ie. a commit can have multiple children and/or multiple parents and that relationship is represented in the tree) means unlimited branching and merging is _trivial_ rather than something that needs careful consideration and a strategy, and believe me this is something that is useful even to an individual developer. Disconnected operation in a best case means things are much faster, and in a worst case means you can still make proper commits even when internet connectivity is lost. This is to say nothing of the myriad of advanced tools and capabilities (eg. interactive rebasing).

    There are legitimate reasons to use SVN (everyone else already using it, designers or other non-technical folks need something simple), but please stop pretending that there is a comparison to be made on a functionality / workflow level. I don’t mean to be a zealot here, use what you want, but the ignorance needs to be put down hard. It’s like trying to argue that Windows is more powerful than Unix–sure there is a ton of cool software available and solutions to most of the same problems, but ultimately the underlying foundation will never measure up.

  38. I just made the jump from SVN to Git today (got a small personal GitHub account), your article made the transition a lot easier, thanks.

  39. @markmcb,

    To me the true power of Subversion was the fact that I have a single, centralized place where I /know/ all my code can be found. Not just the good code, but all the code. If I later need to get access to one of my /bad/ ideas, because I suddenly have some flash of insight that dramatically changes whether it is possible or not, that branch is on the server.

    From this, it really seems to me that git is only designed to do the one thing it was, well, designed for: distributed open source projects that simply isn’t interested in every branch. But, I can’t imagine any situation that would ever come up inside of an organization where the idea of “store information on random developer’s disk drives and only have it commit to the centralized, and therefore easily backed up, revision control system if the developer decides to bother” is a good idea.

    I think the key differentiating factor comes down to this statement:

    “With Git, deleting an abandoned branch is simple and clean. The work done in D will never be seen by the public, i.e., your team. You’ve spared the team clutter both in the logs and on their file systems. With Subversion, the clean up is on you. Should you forget to delete D, it’s has the potential to get used and that could be bad. Conversely, someone else may have quietly checked out D and been working on something. When you delete it from the public repository, their commit will surely fail.”

    I just can’t imagine why this is considered a good thing. First off, “on their file systems” is a strawman: no one checks out an /entire/ Subversion repository (nor should you, as it makes working with branches more difficult), they check out individual subfolders and then svn switch between lightweight copies. Secondly, if developers on the project are randomly checking out branches and doing work on them rather than following some accepted process you have much more fundamental problem to work out with your team than your choice of revision control.

    I want all of the code, all of the time, stored in the one place in the entire building I trust: the file server.

  40. @Jay Freeman,

    I’m not trying to sound attacking, but I think your entire first point is irrelevant. If you want everything on the server always, then simply never stash and never create a local branch. By killing two key features of Git, you easily wind up with a similar tool and process as Subversion. As Jeremy pointed out above, Subversion’s capabilities are a subset of Git’s, i.e., Git can do everything Subversion does, but also has the distributed features. It is entirely possible for you to have a single, central server tracking everything you do. I’ll never understand why you’d want that, but it’s entirely possible.

    I see your points on the branch deletion, but I think they only hold true in overly structured environments, which tend to be good for managers but a pain for developers. To use an example mentioned earlier, what if I’m one of two guys that work on the views for your web site. I personally don’t like the current front page design and have some ideas I’d like to toy with. The other developer is in the process of making tweaks to the current front page. With Git this scenario is simple, I just create a local branch. If my design doesn’t live up to the thoughts in my head, I kill it. If it does, I show you and the team and we decide what to do. Again, you can veto it and no harm is done. With your methodology, I either have to commit it to the server on yet another remote branch, or I have to adhere to your rules that catch “fundamental problems” and prohibit me from trying.

    I found myself constantly wanting to do things like this in Subversion, but I always had to hack it. I’d checkout another copy and simply not commit. The lack of local commits is a problem as I’m losing history. With Git, I may make 20 commits on my local copy, each with a message. With your svn process, I’m going to have one huge change set unless I make a remote branch to commit to (and it sounds like your process would deem that a “fundamental problem” and prohibit it). Your way loses information. My way captures it, but only records it after collaboration.

    And your last point is bogus. If you truly want all the code, all the time, you need to invest in an asynchronous backup system. There is nothing in Subversion that guarantees the developer will commit all the code all the time. As in my example above where I check out another copy to work on, I can simply delete it and you still never know what I did.

  41. Over the past 15 years I have been using CVS, SourceSafe and Subversion. SourceSafe is in my experience a joke, once even having lost the entire repository a day before rolling out a project for a major tv station. CVS was adequate but Subversion has enough notable improvements to make it worth the switch, eg being able to rename files and retain the history. With git the ability to check in changes whilst offline is not enough motivation as I do not remember the last time I did not have a desktop connected 24/7 to the Internet. For a web development project I would rather have a central server where changes can be pushed to staging (where it will be a QA department rather than peer review) and conflicts resolved early before being pushed to live. For a larger software team it sounds worth assessing but for a small web development team I do not currently see the killer feature that will make me shift. It sounds very promising though and is certainly worth keeping a close eye on development.

    Phillip.

  42. @markmcb

    “With your methodology, I either have to commit it to the server on yet another remote branch”
    “With your svn process, I’m going to have one huge change set unless I make a remote branch to commit to”

    Why are these so costly? There is an implicit assumption somehow that remote branches are almost impossible to work with and use. Have you ever tried svk? Its a frontend (console, I don’t mean a GUI frontend) to svn that makes throwing around these remote branches downright trivial (not that it was terribly hard to begin with, but svk helps a lot with complex merge scenarios).

    I’ve actually lived in this world, and it seriously wasn’t hard: one of the companies I worked for used svn and all the developers used svk. Every single concept, whether that code ended up being used or not, was organized in remote branches. When it was ready to go through QA we moved the entire branch to a different location in the branch hierarchy, and QA would slowly work through those and apply them to our trunk. If you didn’t move the branch into the QA folder it didn’t really mean anything, and you could always delete the branches (as, thanks to the magic of revision control, a magic that git seems to not care much about, the work is never lost).

    “The lack of local commits is a problem as I’m losing history. With Git, I may make 20 commits on my local copy, each with a message.”

    Developers at this company also routinely did fine-grained commits of work. I think our Subversion repository was on revision 30,000-something after having only been at the project for a short while. Why is this an advantage of git? It seems to me like you were just misusing Subversion. If you do everything you are currently doing with git with Subversion instead it would all work fine.

    The only thing I can think of is “maybe you have a dial-up modem connection between you and the repository”, which isn’t a realistic assumption. Even then, svk helps you manage distributing your Subversion repository, but in such a way where all changes, all changes, are guaranteed to end up on the server. To me that’s the important feature here: “guaranteed”. The #1 thing I like about revision control is this warm fuzzy feeling that, no matter how badly I screw up using the tool (barring me rm -rf’ing the control files), I can’t lose any data. That does not seem to even be a soft goal of git: there are tons of reasonably commands that don’t yell at you and require you to stop what you are doing that unwind history or delete information in ways that make it never appear on the server. :(

    “If you truly want all the code, all the time, you need to invest in an asynchronous backup system.”

    I am fine losing a few hours of work (the amount of time between when I expect people to be doing commits to their branches to the master server, although that’s going to be more of an average) if a developer machine dies, and I am fine losing a few days of work (the amount of time between major backups) if the file server goes offline. Your model, however, seems to encourage developers to have a lot of information that is sitting around on the disks of individual developers until they are done with what they are working on. That means that you are requiring not just “asynchronous backup”, you are requiring “distributed backup”.

    “As Jeremy pointed out above, Subversion’s capabilities are a subset of Git’s, i.e., Git can do everything Subversion does, but also has the distributed features.”

    Yes, but if I can successfully argue that these distributed features do not provide tangible value, then they are no longer “reasons to switch”. If git also has dancemania features, but those features are not interesting to a majority audience, then you could only list it as a “reason to switch” “if you are part of a dance troupe”. I therefore don’t have to show that git can’t be used in such a way where all of its branches are on the server, I only need to argue that “one would not want to use it in any way but that way”.

    So, I’m not arguing against git as much as I’m arguing against your assumptions over the limitations of Subversion and the needs of version control at a typical organization. Put differently, it isn’t that I’m arguing here that git is fundamentally flawed and inferior, I’m arguing that it has gone out of its way, due to its primary design target, to add features that are not enticing to 99% of the people who use svn and aren’t “reasons to switch” unless you are in that specific category of projects (large, open source projects, where you don’t want to know all of the people working with the code).

    In summary:

    1) remote branches in Subversion are not costly and can be used the same way people use local branches in git
    2) remote branches in Subversion are not difficult (and if you think they are you might try using svk as a frontend)
    3) local branches only provide a greater opportunity for code to get lost and therefore should be avoided
    4) (and here’s where I think there is the most room for argument:) most projects are not distributed, open source projects

    I believe taking those arguments together nullifies git’s “distributed features” as a “reason to switch” for most users. This does /not/ mean one should not use git (as, as you say, you can use git to satisfy this situation if you are careful enough), again: I’m just saying “this is not a reason to switch to git from Subversion”.

  43. @Phillip

    It seems that you and most people commenting here don’t understand the difference between git’s workflow and subversion’s or cvs’s. With CVS and SVN you checkin/commit when your changes are complete and will not “break the build”. With git you can commit as often as you’d like, I’ve even added a commit line to a makefile on one of my projects. When you finish your changes and are satisfied with them, you PUSH them to the remote server (in git a “push” is very similar to a commit in subversion). This will allow you to make big changes, and if you make a mistake you can just revert rather than spending time redoing things from the last revision on the server or “undoing” your work.

    @anyone who doesn’t see a reason for branching:
    … what do you do when you want to develop a new feature or do some major changes that break the application’s functionality for a period of time? Especially when working with a group of people? Do you just let the broken build sit in trunk? I suppose this is only a problem with projects that have a public source repository and users who regularly checkout from it.

  44. @Lee “Are any git plugins available for say IntelliJ or Eclipse or NetBeans”

    There’s certainly a mercurial plugin available for NetBeans. Like git, mercurial is a distributed SCM with the same fundamental concepts, so if you use NetBeans and want to switch away from SVN, mercurial might be a good choice.

  45. @Paul

    “With CVS and SVN you checkin/commit when your changes are complete and will not “break the build”. With git you can commit as often as you’d like, I’ve even added a commit line to a makefile on one of my projects.”

    The general practice is to not merge to trunk something that will break the build, but I see no reason why you don’t do this “commit early and often” to your personal branches with Subversion. Doing commits to Subversion is seriously not costly or difficult. Why do you feel that you can’t use Subversion in this manner? The only difference seems to be that git encourages you to keep your branches private and local to your machine, whereas Subversion requires that your branch be “public” and stored on the centralized server.

  46. @Jay Freeman,

    Fair enough. I see why you’re content with Subversion. But let’s be honest, any tool that comes with a dancemania feature built-in is worth switching to. :-)

  47. @Jay Freeman
    “Doing commits to Subversion is seriously not costly…”

    The problem with SVN isn’t doing commits, it’s doing merges. A secondary problem is that SVN isn’t distributed (although clearly this isn’t a problem for you because you never do development at home, on a different computer, on an airplane, behind a restrictive firewall, or somewhere with a lousy/non-existent internet connection).

    Creating a branch on SVN isn’t painful, but merging it back in is. That’s why people are reluctant to create branches in SVN. Your response to that is a classic instance of what Jeremy described earlier: I have a pile of band-aids to work around the difficulties, therefore I don’t need a better tool.

    You can certainly concoct situations in which git offers no advantage over SVN, but you should step back and ask why you’re limiting yourself so much. Throw away the limitations and adopt a more flexible tool, and you might be surprised at what you discover.

  48. I have a correction for the article: in the stash section, task 3 in the box should say “git stash apply [stash name]”, not “git apply [stash name]”

  49. distributed version control is not for everyone

    too many people are enamored of a tool or something because it’s new

    every organization has it’s own situation and needs

    getting a full repository and allowing people to work in silos without collaboration is not necessarily a good thing

    git addresses the needs of linux kernel development, with many contibutors funnelling to a gatekeeper

    some development shops benefit from a locking checkout model which forces developers to communicate and plan

    subversion has a lot of users and knowledge pool; this can be important for some situations

    distributed model has it’s plusses; getting all the history, changes, diffs, etc, while offline can be real helpful, but it all depends on the nature of the development and the developers

    no one tool or process is ‘right’ for everyone

  50. It seems to me from listening to the discussion here and elsewhere that it really boils down to differing usage profiles:

    If you tend to do a lot of disconnected work, if you tend to do lots of branching and merging, or if you do gatekeeper style development, you don’t understand how anyone could live in SVN. You feel locked in a box if you try.

    If you do 100% connected development, rarely merge branches, or do highly structured “one true repository” model development, you can’t understand why anyone would care about Git. You feel lost in the fog if you try.

    There, I’ve successfully oversimplified everything. It’s hard work, but somebody had to.

  51. Thanks for this nice article.

    Here are some other detailed reasons to migrate to git: http://harryseldon.thinkosphere.com/2008/11/08/grand-gardening-with-git .
    Basically, yes git is very efficient even when it is used like svn. But imho git is amazing when it is used as a DVCS. That is, if at some point you thought “I’d like to have 2 repositories talking to each other” then you are ready to migrate to git.
    By the way, I am using an IDE. And even if git is not yet very nicely integrated in eclipse it does not really bother me.

  52. Just started the switch and I find it hard to believe that nobody mentioned integrity. Since git uses SHA1 for every commit it is virtually impossible to corrupt a git repository without noticing.
    Combining this with a cryptographic signature of a single commit as is possible with git tag and GPG and you have a fool proof way of making sure that your sources have not been tempered with.
    I’m unaware of the fact that SVN has this builtin capability.

    The second thing I find git superior is simply the fact that it is distributed and that it is possible to host a public repository and enable others to work on it while having a private repository you can do your own sh… with. And it doesn’t matter if you work on your private repository or on the public one as all changes can be pulled to each repository as needed. I could not get this to work in SVN (svnsync is useless). Granted there is SVK which I haven’t looked at closley but the way I see it there is still a master repository. And we all know single points of failure are always bad.

    And the last fact is simply performance git is so much faster with most operations that working with it is a breeze.

  53. Our central repo is a subversion repo, and about 4 months ago, I switched over to git-svn to access it. Like many here I was skeptical about the usefulness of git, but I have been pleasantly surprised. Even for a simple subversion workflow (I don’t do a ton of branching / merging, for example), git is *fast*. I look through my history a lot more, make many, many more commits, and in general, use the versioning system more. I like the two stage commit process. As others have mentioned, Git’s features are a superset of those of svn. To me, the workflow, while having more steps, feels more *rational*. Git stash is killer and git rebase –interactive is a joy to use.

    It is also nice that the checked out directories only have one .git directory, instead of a .svn directory in every subdir, making it very easy to copy Git-tracked trees. Git is pretty transparent in its working.

    Caveats: I use command line tools only, no GUI, no IDE, so YMMV.

  54. Pingback: Six Resources To Study And Master Git Source Control

  55. Some of you have mentioned that the merging in Git is easier than SVN. Why? What are the issues with merging in SVN that Git handles better?

  56. Good article, it’s certainly created quite a bit of debate.

    We use Subversion at work, although have been toying with the idea of using Git. As mentioned though I think I prefer quick and small commits to the server where the data is more secure. We work in a very Agile setup, so if anything does get broken, it gets fixed straight away.

    Also tools such as TortoiseSvn are much more mature than TortoiseGit. And VisualSVN, there is no VisualGit equivalent.

    However I do like Git. I use it at home now, and will continue to do so, and possibly one day will apply it at work. Switching source control system is a lot of pain though, and at the moment Git doesn’t offer us any huges improvements.

  57. git rocks.

    one thing that i did not see surface was ANY mention of git hooks. this, along with branching, merging, and simple backups, are the killer features in git for us. git can use any executable file as a hook, be Python/PHP/Ruby/C++/Bash/whatever.

    my team of 5 develops for a small company whose primary income is a member driven website, and the primary language is PHP. before, with svn, we were all continuously stepping on each other by editing various layers of the software stack. we did not deal with branching/merging in svn as its too cumbersome, period, and we all work from a CLI/SSH interface to distributed webservers. i remember several instances where layers below me or another dev were broken by a different developer, and i/he wasted 20+ minutes trying to figure out what was wrong with my code. this is where local topic branching is key; as i can always be fairly certain that the code in trunk/master/head/whatever is clean and not stupidly broken from the changes others are making right now on their own feature x/y/z.

  58. for some reason (bad input filtering) it wouldnt let me post my whole comment so here is the rest of above…….

    however, git hooks are my single most favorite thing about git; examples:

    1) pre-commit hook on developer repos to check for syntax errors in *.php files. awesome.
    2) commit-msg hook on developer repos to force conformance of commit messages to a defined spec.
    3) post-update hook on developer repos to link updates/squashes to a custom ticketing system and close the ticket if we like.
    4) we use a series of hooks to let us sync/push changes to staging_master to ALL DISTRIBUTED WEBSERVERS INSTANTLY. we also use a callback system so ensure that all servers get the update, then a time is pushed, and all servers update AT THE SAME SECOND. before this we would “svn update” on each server manually; we use our SCM as a means to “launch” changes.
    5) we do the same thing as #4 but with the production copy to make changes sitting on staging sync with production, once staging has been confirmed to be working as expected.
    6) not a hook, but each developer gets a full working tree and never interferes with another developer. they can go to dev_name.dev.example.com, to test their personal copy, stage.dev.example.com, to test the staged (master) development copy (merged work from various devs), stage.example.com, to see the staged production copy and so on.
    7) we use a “hub” copy on each production server that acts as a buffer to the real, checked out copy that people see when they access the website (git says to never push/pull to a repo that has a working copy). this is pretty cool see #8.
    8) post-commit hook to guarantee that committed (key word COMMITTED) changes made to ANY live server get immediately pushed to the master copy on the dev server, AND instantly (relatively) reflected to ALL OTHER PRODUCTION SERVERS. sounds a little dangerous, heh and maybe it is, but it keeps everything in sync and allows for last second, sh!t is down dirty little changes. should never happen, and it hasnt yet, but still cool.

    all this lets us, the devs, work as a group but not affect/break/slow/confuse each others progress on whatever. also, another cool thing is we track each others repos, so if one dev has problems/bugs/whatever, ANY of us can diff his branch against ours if we want, or checkout their branch(es) and help them solve the problem from our own machine, WITHOUT EVER TOUCHING MASTER.

    we can develop, test, and launch without ever leaving the development machine.

    as others have said, git’s power is the fact that it’s less of an SCM itself, and more a tool for letting YOU define what an SCM means to the workflow and structure of your company.

  59. I’ve been working as a sole developer for a backend website for about a year now. Technically, I’m *not* looking for a VCS for that system anymore, because my employer decided to go with SVN, and also because we’re moving to an open-source replacement for the backend. But, from what I’ve been reading of the comments, I have a few observations to make:

    First, for personal projects (and I have several), having a Version Control System would be better than periodically re-naming working files as something like “myproject-III.py”, which is my current practice.

    Second, even as a sole developer for a backend website, there were times in which I was in the middle of some sort of substantial change, and my employer would say “There’s a bug somewhere here. Could you fix it?” Well, yes and no: I’m sure it will be easy to fix (and it often was), but now I’ll have to update the “Live” version with that bugfix…except that “Testing” is in the middle of this big change, and is not at all ready to deploy…furthermore, I have to make sure that the change I just made is applied to both “Testing” and “Live”. I tried to add a third version for this, called “Debugging”, but that introduced even more complexities!

    Third, it would seem that having a centralized VCS would be overkill for this, and for my personal use. The reason my employer is using SVN is because he has a couple of developers on the main website as well.

    Overall, I will likely be using Git for personal use! And it would seem that I’m going to wish that my employer would use Git as well.

  60. Thanks for the article, I have been using SVN for the last 5 years and I simply love it. Based on above comments, it seems Git offers some good DVCS based features which probably will be included in SVN too by v2.0.

    I would like to know, How does Git handles authentication? Is windows domain based authentication supported?

    I have one doubt for Git i.e. if every dev. copies the whole repository locally, how come Git is faster then SVN? What about disk usage for large projects?

    Personally I think, It would be hard for Windows based shop to make a switch to Git as of today due to lack of integration with 3rd party tools like Trac, GUI clients like Tortoise SVN, Subclipse etc (But anyways like you said that’s beyond the scope of your article).

  61. So nice post! I agree. IMHO, Git is better than SVN. If you could talk about the merge function that git has, and that is SO MUCH BETTER than SVN, than you’d found another reason to change from SVN to GIT. Really nice post, and congratulations to have patience to find examples that we really live on the work days.

  62. You guys are a bunch of nuts. All I can tell is you never learned how to create branchs in SVN or work somewhere where your account level doesn’t allow you to do it. GIT seems cool for a local source control solution. If you use it the way you need in a normal large dev group then you might as well use SVN. If you have “maintainers” or check-in czars, then the whole scenario is changed. One big thing on projects is to be abel to track the work of others. GIT tends towards individual development as explained by the OP and many others in this posting. Great for prototype type people but not great when you are the PM.

Comments are closed.