


How does Git improve upon Subversion?

locked by Bill the Lizard Mar 22 '12 at 12:20


Read more about locked posts here.

30 Answers 30



















  • 70
    A Ferrari is not better than a Hyundai. But is also not worse. It's different. (What? Don't stare ME this way... Did I say something wrong?) – F.D.Castel Jan 19 '09 at 3:13
  • 219
    No, you didn't. A Ferrari is impractical, expensive, thirsty, and will not get you better from A to B if you live in a city like New York or Paris - I'd prefer a Hyundai for many places, also because a scratch is much less severe. But to each his own - a Ferrari has (very few) advantages as well... – Michael Stum Jan 19 '09 at 7:29
  • 50
    Distribution is not the only difference between Subversion and Git. It also doesn't add any complexity unless you use multiple repositories. There are many advantages of using Git instead of Subversion, but only a few (mostly insignificant) disadvantages. Git is used because it's good, not shiny. – sebnow Feb 11 '09 at 5:40
  • 12
    I'm amazed this is the top voted answer! (AFAICT from git affectionados) git is not just svn with offline - its a whole new life-changing revelation. I suspect this was voted up by svn fans sick of hearing about how great git is. – Paul Biggar Aug 7 '09 at 15:10
  • 8
    @steve314: Sorry for the late response. The type of woman who is impressed by your car or choice of VCS is shallow and likely to be high-maintenance. She'll drop you in a heartbeat for a guy with some new-fangled quantum-entangled VCS that makes your commits instantly available in all copies. – Hugh Brackett Jul 24 '10 at 18:11


Making branches and merging between branches is really easy.






Drawbacks of Git:

  • revisions don't have version numbers like in subversion
  • 31
    Although learning all of Git would be much harder, the basics are almost identical. The learning scope isn't really that steep until you get into the more advanced stuff, which SVN is simply not capable of anyway. – sebnow Feb 12 '09 at 10:31
  • 10
    +1 for me. I think a lot of developers forget that git is lacking something like TortoiseSVN, and that not only developers use version control. I shudder at the thought of having to explain (and support) distributed version control to our non-developers using SVN|TortoiseSVN! – si618 Mar 23 '09 at 16:42
  • 12
    I'm SVN user, but - try this: code.google.com/p/tortoisegit – DiGi Jun 22 '09 at 12:35
  • 7
    another disadvantage - you have to have a full copy of the repository, you can't work on partials (which matters if you have huge ones, like a lot of corporates) – gbjbaanb Aug 7 '09 at 15:09
  • 3
    I love git, but it took me about six months of daily use to really use it effectively. That being said, I use a combination of the git shell (command prompt) from msysgit, git gui and gitk from msysgit, and TortoiseGit. I think TortoiseGit is great, but I don't understand why more people don't use it. I know the msysgit maintainers loath TortoiseGit for various reasons, some of them ideological, and that may have something to do with it. TortoiseGit is a well-kept secret! – Jim Raden Aug 7 '09 at 19:59


  • 2
    Ad. 7. With modern git you can also have per-user "private" ignore setting by using core.excludesFile configuration variable in ~.gitignore (see man git-config). – Jakub Narębski Feb 23 '09 at 10:41
  • 3
    Re #5: While this is normally true, sometimes Git does screw this up. At least with Subversion, problems due to move or delete are almost invariably a PEBKAC. While it's nice to have automatic move/delete tracking, I'd still at least appreciate the ability to explicitly state what I'm doing to files in the repository, even if I don't need to use it. – Chris Charabaruk Aug 28 '09 at 0:17
  • 8
    @Chris: You can do it explicitely: git mv and git rm. – R. Martinho Fernandes Sep 10 '09 at 10:57
  • 2
    I would also like to see the option of a single .svn directory per working copy, but for the record: For #3: Most tools will (by default) ignore .svn directories. For #6: You can set properties recursively. – si618 Oct 13 '09 at 6:05
  • 6
    3: "a single .svn" directory will be here with SVN 1.7 when WC-NG is implememnted. 1: To get SVN cleanup you 'export' over the top of your WC. 5: its not so easy, if you rename a file does git recognise it and keep history, or treat it as an add and delete in the directory?. 6/7: svn has global-ignores per user client setting. – gbjbaanb Oct 15 '09 at 21:25



  • Git tracks content rather than files
  • … and a lot more.

There are some disadvantages:



svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"


git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Where Git really shines is branching and working with other people.

  • 8
    You say GIT tracks content rather than files. I discovered that SVN also does that: I just made changes to a file, and saved it. SVN showed the file as red(changed). Then I did undo in the editor and saved it again. SVN then updated the status to green (not changed) even if the file was changed (change date newer) but SVN recognised that the content was not changed from the original. – awe Oct 7 '09 at 8:35
  • does svn track changes accross files? – Seun Osewa Mar 3 '10 at 23:55
  • 12
    @awe, that's called file tracking. try renaming the file, or moving it somewhere else manually [same content, new file (because of the new path/name)]: will SVN know that that's the same file and retain the previous countless revisions you've made to it? no, I guess not. – Filip Dupanović May 18 '10 at 21:07
  • TortoiseGit - code.google.com/p/tortoisegit | Git 1.7 sparse checkouts - kernel.org/pub/software/scm/git/docs/RelNotes-1.7.0.txt – Zaz Aug 19 '10 at 10:45

Google Tech Talk: Linus Torvalds on git


The Git Wiki's comparison page


  • 12
    Linus' talk is fun to watch. He brutally rips centralized version control systems like Subversion and CVS. However, Randal Schwartz' youtube.com/watch?v=8dhZ9BXQgc4 talk is more constructive, more informative and more convincing. – bendin Nov 10 '08 at 7:44
  • 2
    This one is quite nice too. Its from one of the git commiters and he explains many advanced features like splitting large commits into smaller ones. youtube.com/watch?v=j45cs5_nY2k – schoetbi Sep 23 '10 at 18:22
  • I do enjoy that Linus Torvalds video, but he implies that git is distributed, not centralized, and this is just wrong. It can be used in a distributed way, OR in a centralized way. You can have one central repository that everyone commits to, just like in SVN. It's just that you don't have to do it that way. – MatrixFrog Dec 1 '10 at 8:53
  • @MatrixForog: I think that in this case, "decentralized" is not the opposite of "centralized" but really a superset. It's like "mobile" and "immobile"--just because something is "mobile" does not me it can't stand still. – Tikhon Jelvis May 29 '11 at 17:56





  • 1
    The cause why Git can take less disk space for full repository than Subversion for mere checkout is that Subversion stores "pristine copy" to make 'svn diff' (comparision with last version) work... and that git repository is compressed (and deltaified). – Jakub Narębski Feb 11 '09 at 14:58
  • 3
    I am not surprised git "working folders" (i.e., repos) are smaller than svn working copies because even svn repos are smaller than svn working copies. – R. Martinho Fernandes Sep 10 '09 at 11:02

The main points I like about DVCS are those :

  2. Because of this you can commit more often.
  7. It's fast (even on Windows )


  • I think point #1 intends to say "other people won't see them until you publish" (or "push"). – jackr Nov 22 '10 at 18:52
  • Thanks, you are right. Fixed. – Emmanuel Caradec Nov 23 '10 at 11:07
  • +1 "You can commit broken things." is the main reason why I'm considering switching to git from svn. I always hate when I'm midway of developing a heavy code block, and I don't have the safety net of VCS (simply because my modifications do not work yet, so I'm not allowed to commit). – András Szepesházi May 4 '11 at 9:38


Please read Develop with Git on a Google Code Project


Using Git on a Svn Repository gives me benefits:

  3. And they are free to use Git for their own
  • 3
    this is kind of out of date, google code does mercurial so there is not need for this hack anymore – Sam Saffron Jan 11 '10 at 10:32
  • @Sam unless you happen to like git and/or dislike mercurial. – MatrixFrog Dec 1 '10 at 8:58

All the answers here are as expected, programmer centric, however what happens if your company uses revision control outside of source code? There are plenty of documents which aren't source code which benefit from version control, and should live close to code and not in another CMS. Most programmers don't work in isolation - we work for companies as part of a team.

With that in mind, compare ease of use, in both client tooling and training, between Subversion and git. I can't see a scenario where any distributed revision control system is going to be easier to use or explain to a non-programmer. I'd love to be proven wrong, because then I'd be able to evaluate git and actually have a hope of it being accepted by people who need version control who aren't programmers.

Even then, if asked by management why we should move from a centralised to distributed revision control system, I'd be hard pressed to give an honest answer, because we don't need it.

Disclaimer: I became interested in Subversion early on (around v0.29) so obviously I'm biased, but the companies I've worked for since that time are benefiting from my enthusiasm because I've encouraged and supported its use. I suspect this is how it happens with most software companies. With so many programmers jumping on the git bandwagon, I wonder how many companies are going to miss out on the benefits of using version control outside of source code? Even if you have separate systems for different teams, you're missing out on some of the benefits, such as (unified) issue tracking integration, whilst increasing maintenance, hardware and training requirements.

  • IMHO, this is the only valid reason to favour SVN. In short, it's easier to explain to a non-programmer, that is, someone who expected to use it in a linear way and avoid complex (=real) VC scenarios: conflicts, 3 way merges,branches.. I mean, you would never want to let the VCS merge a powerpoint presentation file anyway.. – inger Jul 27 '10 at 19:16
  • 2
    "Most programmers don't work in isolation" seems to suggest that accountants/marketing people would have to use the same repo where the source code is kept. I don't see the benefits of this; some my ex companies wanted to standardize on things like that, but it inevitably failed. I think the simplistic approach can be great for manager but an oversimplification for programmer teams - so unifying these leads to a bad compromise. – inger Jul 27 '10 at 19:22
  • For documents that go with the software, you're right - they should be versioned together. I found that those much less than people think initially (we ended up throwing out a huge tree docs from the source repo). Also, there is a lot you can do to simplify workflows of tech writers, etc, should it be an issue (it should not). – inger Jul 27 '10 at 19:31
  • 2
    @inger I don't think you can say "this is the only valid reason", AFAIK tooling support for Subversion is far superior to Git, e.g. TortoiseSVN and integration with Visual Studio and Java IDE like Eclipse. That may not be an issue for you, but it certainly is for us. I didn't mentioned it in my answer because it's a separate issue. – si618 Jul 28 '10 at 0:56
  • 1
    @Keyo, yes it's true non-programmers will take time to get Subversion, but I think they will take longer with git or Hg. Wiki's are great if they get maintained, but in my experience developers are more likely to maintain documents which are related to source code if they are close to that source code. I agree with inger in that there aren't that many documents that fit this category, but they certainly exist. It's interesting you say git/Hg are the best tool for the job, that's a blanket statement that probably isn't true for all circumstances, does git and Hg have as good integration as SVN? – si618 May 4 '11 at 6:08

Subversion is still a much more used version control system, which means that it has better tool support. You'll find mature SVN plugins for almost any IDE, and there are good explorer extensions available (like TurtoiseSVN). Other than that, I'll have to agree with Michael: Git isn't better or worse than Subversion, it's different.

  • But now, after using git extensively for a couple of years, I need to disagree with myself: Git is far better than Subversion. At least once you get over Git's unfriendly syntax. – neu242 Sep 20 '11 at 12:39

One of the things about SubVersion that irks me is that it puts its own folder in each directory of a project, whereas git only puts one in the root directory. It's not that big of a deal, but little things like that add up.

Of course, SubVersion has Tortoise, which is [usually] very nice.

  • 5
    the .svn dirs will be gone soon, probably with v1.7 – gbjbaanb Aug 7 '09 at 15:11

David Richards WANdisco Blog on Subversion / GIT



  • 1
    Note that David Richards could be unbiased: the product he makes is based on Subversion (or on Subversion ideas), so of course he would be pro-Subversion and anti-Git. – Jakub Narębski Sep 20 '10 at 9:21
  • 2
    Ironically, Git was created specifically because software engineering doesn't happen on islands. This quote is moronic. – Ben Collins Jan 25 '11 at 19:29
  • Although I use git I would also be quite happy to work with any decent DVCS like Mercurial for example. It takes time for the DVCS concept to gain popularity and now I see a huge number of open source projects have switched to git. – Keyo May 3 '11 at 21:21
  • By painting the svn detractors as fundamentalists, David is side-stepping the fundamental issue: the subversion architecture is a dead-end. It's not that git is the end-all-be-all of VCS, it has its warts to be sure, but git, mercurial, darcs and many other VCSes all have fundamentally more elegant repository models. Subversion will never make merging work because the directory == branch model makes real progress impossible. Companies like David's can keep caking more and more lipstick on a pig, but svn will inevitably fall further and further behind the state of the art. – gtd May 25 '11 at 19:04

Git also makes branching and merging really easy. Subversion 1.5 just added merge tracking, but Git is still better. With Git branching is very fast and cheap. It makes creating a branch for each new feature more feasible. Oh and Git repositories are very efficient with storage space as compared to Subversion.


It's all about the ease of use/steps required to do something.

If I'm developing a single project on my PC/laptop, git is better, because it is far easier to set up and use. You don't need a server, and you don't need to keep typing repository URL's in when you do merges.

If it were just 2 people, I'd say git is also easier, because you can just push and pull from eachother.

Once you get beyond that though, I'd go for subversion, because at that point you need to set up a 'dedicated' server or location.

You can do this just as well with git as with SVN, but the benefits of git get outweighed by the need to do additional steps to synch with a central server. In SVN you just commit. In git you have to git commit, then git push. The additional step gets annoying simply because you end up doing it so much.

SVN also has the benefit of better GUI tools, however the git ecosystem seems to be catching up quickly, so I wouldn't worry about this in the long term.

  • 11
    The separation of committing from publishing in Git is IMHO advantage rather than disadvantage. – Jakub Narębski Feb 11 '09 at 14:59
  • Ok, so how would you rate the "ease of use/steps required to do something" for SVN when: - making a topic branch for experimentation - merging this branch into another branch - splitting edited stuff in a file into their own smaller commits - quickly checking out a main branch to make a small fix IMHO I don't see how setting up an SVN server is easier than setting up your git server. And why you'd want to give up all the nice advantages you get from lightweight branches just so you don't "have to push separately". – Sam Sep 30 '10 at 14:03
  • The "topic branch for experimentation" argument is often put forward in git's favour, but honestly, I've never actually seen anyone actually do that in subversion or another non-DVCS system. Perhaps it's a big deal and we're all missing out, but from what I've seen 99% of developers (myself included) don't care about topic branches because they never use them! - You can't miss what you've never had :-). I think if DVCS people are going to put forward "topic branches" as a feature, they first have to convince everyone that such things are actually useful. – Orion Edwards Sep 30 '10 at 19:32
  • The "splitting edited stuff into smaller commits", again, is something that sounds nice in theory. But, in the last 3 years, I've not once thought "oh, I wish I could do that", and I struggle to even come up with a hypothetical situation where I might want the feature... A lot of the git/DVCS advocates simply say "we have X and X is awesome" and everyone else is sitting there wondering why on earth they'd ever need X – Orion Edwards Sep 30 '10 at 19:36

Easy Git has a nice page comparing actual usage of Git and SVN which will give you an idea of what things Git can do (or do more easily) compared to SVN. (Technically, this is based on Easy Git, which is a lightweight wrapper on top of Git.)


Git and DVCS in general is great for developers doing a lot of coding independently of each other because everyone has their own branch. If you need a change from someone else, though, she has to commit to her local repo and then she must push that changeset to you or you must pull it from her.

My own reasoning also makes me think DVCS makes things harder for QA and release management if you do things like centralized releases. Someone has to be responsible for doing that push/pull from everyone else's repository, resolving any conflicts that would have been resolved at initial commit time before, then doing the build, and then having all the other developers re-sync their repos.

All of this can be addressed with human processes, of course; DVCS just broke something that was fixed by centralized version control in order to provide some new conveniences.

  • 1
    Actually if you look like Linux kernel or git project itself is managed, you would see that Git is very good for 'single maintainer' (or maintainer + lieutenants) workflow, with one central by consens repository. And it makes easy to switch temporaritly to someone else as a maintainer. – Jakub Narębski Feb 23 '09 at 10:44





A few answers have alluded to these, but I want to make 2 points explicit:

1) The ability to do selective commits (for example, git add --patch). If your working directory contains multiple changes that are not part of the same logical change, Git makes it very easy to make a commit that includes only a portion of the changes. With Subversion, it is difficult.

2) The ability to commit without making the change public. In Subversion, any commit is immediately public, and thus irrevocable. This greatly limits the ability of the developer to "commit early, commit often".

Git is more than just a VCS; it's also a tool for developing patches. Subversion is merely a VCS.

  • 4
    Re 1) If you're using TortoiseSVN, AnkhSVN, etc. then it's very easily (trivial) to select which files with changes to commit. Re 2) If you don't want other devs to get your code, create a branch and then merge when ready, it's not hard. – si618 Apr 9 '10 at 7:45
  • irrevocable? Well you could reverse merge the faulty commit and the repository is as it was before. But you are right it is documented. But is this good or bad? I guess it depends... – schoetbi Sep 23 '10 at 18:31
  • @schoetbi No, the head of the repository is as it was before. The repository itself now contains two commits, whereas it would be nice if neither of them was there. It's extra clutter that slows you down when you're looking through the logs. Of course, this can happen with git too, especially if some developers are in the habit of pushing immediately after committing. But it's much easier to avoid in git. – MatrixFrog Dec 1 '10 at 9:06




For more details on a merging story, see this : Using git-svn (or similar) *just* to help out with an svn merge?


Thanks to the fact it doesn't need to communicate with a central server constantly, pretty much every command runs in less than a second (obviously git push/pull/fetch are slower simply because they have to initalise SSH connections). Branching is far far easier (one simple command to branch, one simple command to merge)


I absolutely love being able to manage local branches of my source code in Git without muddying up the water of the central repository. In many cases I'll checkout code from the Subversion server and run a local Git repository just to be able to do this. It's also great that initializing a Git repository doesn't pollute the filesystem with a bunch of annoying .svn folders everywhere.

And as far as Windows tool support, TortoiseGit handles the basics very well, but I still prefer the command line unless I want to view the log. I really like the way Tortoise{Git|SVN} helps when reading commit logs.















Articles can be found on his blog, www.ericsink.com:


For people looking for a good Git GUI, Syntevo SmartGit might be a good solution. Its proprietary, but free for non-commercial use, runs on Windows/Mac/Linux and even supports SVN using some kind of git-svn bridge, I think.

  • Looks good, would be great if they had SmartHg as well! – Regent Mar 9 '11 at 17:26






  • Obviously biased, as his tool is based on Subversion. Just saying. – Jakub Narębski Jul 27 '10 at 18:12

Git in Windows is quite well supported now.

Check out GitExtensions = http://code.google.com/p/gitextensions/

and the manual for a better Windows Git experience.


I have been dwelling in Git land lately, and I like it for personal projects, but I wouldn't be able to switch work projects to it yet from Subversion given the change in thinking of required from staff, without no pressing benefits. Moreover the biggest project we run in-house is extremely dependent on svn:externals which, from what I've seen so far, does not work so nicely and seamlessly in Git.






Why I think Subversion is better than Git (at least for the projects I work on), mainly due to its usability, and simpler workflow:

