Stack OverflowWhy is Git better than Subversion?
[+393] [30] Ben Mills
[2008-08-03 22:38:29]
[ svn git ]
[ ]

I've been using Subversion [1] for a few years and after using SourceSafe [2], I just love Subversion. Combined with TortoiseSVN [3], I can't really imagine how it could be any better.

Yet there's a growing number of developers claiming that Subversion has problems and that we should be moving to the new breed of distributed version control systems, such as Git [4].

How does Git improve upon Subversion?

[+547] [2008-08-03 22:45:44] Michael Stum [ACCEPTED]

Git is not better than Subversion. But is also not worse. It's different.

The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.

With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.

With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.

This looks good at first, but just keep in mind the added complexity to this approach.

Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.

Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.

Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.

First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "git init" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.

Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").

As said above: Git adds complexity. Two modes of creating repositories, checkout vs. clone, commit vs. push... You have to know which commands work locally and which work with "the server" (I'm assuming most people still like a central "master-repository").

Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.

SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.

Git has the advantage that it's MUCH better suited if some developers are not always connected to the master repository. Also, it's much faster than SVN. And from what I hear, branching and merging support is a lot better (which is to be expected, as these are the core reasons it was written).

This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.

What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.

But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.

(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
(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
(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
(4) That's the conclusion if you really spent some time investigating it AND if you have the tools for it (Sure, you have to know all the command line tools of your CVS, but that does not mean that people really like to use them all the time). As said, many people (i know) said Git = Good because Linus - Michael Stum
(3) I also think GIT advocacy could take this to heart. You can hammer on principles and who is using it for years, but after the first time that is filtered out. It could use a more practical explanation (like how the workflow typically looks like) instead of the abstract discussions. - Marco van de Voort
(6) My experiences with git aren't exactly a "Life changing revelation". I consider it a great tool when it works, when when it doesn't then it feels rather unpolished. I wasn't too impressed debugging stuff like Question 1052882, and even though that is clearly an RTFM Problem: I do consider git (and any other distributed vcs) to be more complicated than centralized ones, and I would consider using it in centralized environments. But then again, i'm mainly a Windows developer, and the tools are still immature on Windows compared to SVN. - Michael Stum
(4) Newflash: People other than developers use revision control systems. Look, I'm sure git is the second coming, but as an svn admin, we have non-developers using it (mostly through TortoiseSVN), and I'm 99% sure that if our developers demanded git, I'd be maintaining 2 revision control systems instead of one. As an aside: how many issue and bug tracking systems allow multiple RCS to be configured? - si618
(2) I've made a few additions, as the last 12 months really sold me on Git. It's still a very steep learning curve and the tooling isn't exactly great on Windows, but once learned it's excellent. I don't want to sound like an advertiser, but TekPub's Mastering Git series helped me understanding it, especially the (for me) hard and critical thing about "How Remotes work". - Michael Stum
(1) @Michael: what's different about software is that cloning costs nothing (almost). Therefore, only one design has a right to live. There's virtually no market to share, which is why it is not like cars. - Pavel Radzivilovsky
It should be noted that Jira allows more than one repository and more than one type of repo to be configured at a time for those that are interested or have different needs for revision control. - krystan honour
(3) @hasen Only if you get over the much steeper learning curve. I absolutely love it, But in environments where you still have to sell the concept of Source Control to your devs (which most of the time means a Windows using development shop), SVNs superior tooling and simplicity simply beats git by miles. If (and that's an "if", not a "when") your devs are really using Source Control, then git can start to shine. I would never use SVN again, but a ton of people would never use Git if it doesn't properly integrate into their tools and if they don't understand the concept. - Michael Stum
(4) @Michael Stum: the "git is hard" meme is totally a myth. I find git to be a lot easier than svn. I never really understood subversion; git just makes sense. Though I agree with you @ it can be a bit harder to sell to the windows guys. - hasen
(4) OP seems to be confused about Git, or I'm misunderstanding. There aren't "two modes of creating repos," git clone ~~ svn co, git push ~~ svn ci, git commit ~~ svn add/rm/etc. Git is only difficult to learn if you have preconceptions of how VCS work. I started with mercurial, went to git, and then had to learn SVN. Guess which was the most difficult to use? SVN! I started using git-svn because SVN is so horrible. There's nothing "proper" about how svn uses the term "checkout". - sebnow
@sebnow I was referring to git init vs. git init --bare - Michael Stum
Ah, in that case I would assume svnadmin create ~~ git init --bare. The only difference between --bare and normal is that a normal repo has a working directory (files are checked out). This is typically only used as a server/central repository and can be ignored by the typical user. In that sense, SVN has "two" ways of creating repos as well; svnadmin create and svn co. - sebnow
(5) You only analyse the distribution aspect in the comparison. I'll tell you why. Because you only want to share code. Git and SVN are more than that, have you ever tagged, branched, merged, resolved conflicts, copy patches among branches? I think your analysis is just flawed. In those aspects, git is a MUCH powerful tool. Not to mention things that git can, and SVN can't, like squashing, disecting, ammending, rebasing, cherry-picking, and much more things. - Martín Schonaker
Uh, you can just host a svn server on your local computer? - bevacqua
When people say that Git is faster than Subversion, are they comparing Git local check-ins to Subversion remote check-ins? That doesn't seem like a fair comparison, since local check-ins aren't in the central repository for others to see, and won't be backed up if your local copy gets corrupted or lost somehow... - Chris Jaynes
(4) sorry but i had to give this one a down-vote. Not really to the point at all and no good arguments plus confusing mashup of clone and checkout which are two entirely different operations! - gilligan
(2) @gilligan, I agree. The only thing good about this answer I found: it's polically correct ("no better/no worse, just different"). - inger
(1) I'm going to have to throw in with the "Git and/or Hg is a life changing revelation" crowd. IMO, git > svn, hg > svn, git == hg. Subversion uses an inherently broken internal model for it's repository. - haydenmuhl
Git is better than svn. Objectively. Factually. Anyone who claims otherwise either doesn't know git and is trying to rationalize avoiding the investment to learn it, or is simply being irrational about the evaluation because they have some kind of emotional ties to SVN. - Charlie Flowers
[+145] [2008-08-04 00:24:15] Michiel de Mare

With Git, you can do practically anything offline, because everybody has their own repository.

Making branches and merging between branches is really easy.

Even if you don't have commit rights for a project, you can still have your own repository online, and publish "push requests" for your patches. Everybody who likes your patches can pull them into their project, including the official maintainers.

It's trivial to fork a project, modify it, and still keep merging in the bugfixes from the HEAD branch.

Git works for the Linux kernel developers. That means it is really fast (it has to be), and scales to thousands of contributors. Git also uses less space (up to 30 times less space for the Mozilla repository).

Git is very flexible, very TIMTOWTDI (There is more than one way to do it). You can use whatever workflow you want, and Git will support it.

Finally, there's GitHub [1], a great site for hosting your Git repositories.

Drawbacks of Git:

  • it's much harder to learn, because Git has more concepts and more commands.
  • revisions don't have version numbers like in subversion
  • many Git commands are cryptic, and error messages are very user-unfriendly
  • it lacks a good GUI (such as the great TortoiseSVN [2])

(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
(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
(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
(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
(2) I agree. I use both SVN and GIT (since about 6 months). I honestly love git a lot more than I ever did SVN. It just takes time to learn it. The biggest leap for me (the moment I saw the light :P) was when I finally realized I had to stop trying to use GIT the way SVN worked. Then everything fell in place ;) - Blizz
[+110] [2008-09-26 00:18:38] andy

Other answers have done a good job of explaining the core features of Git (which are great). But there's also so many little ways that Git behaves better and helps keep my life more sane. Here are some of the little things:

  1. Git has a 'clean' command. SVN desperately needs this command, considering how frequently it will dump extra files on your disk.
  2. Git has the 'bisect' command. It's nice.
  3. SVN creates .svn directories in every single folder (Git only creates one .git directory). Every script you write, and every grep you do, will need to be written to ignore these .svn directories. You also need an entire command ("svn export") just to get a sane copy of your files.
  4. In SVN, each file & folder can come from a different revision or branch. At first, it sounds nice to have this freedom. But what this actually means is that there is a million different ways for your local checkout to be completely screwed up. (for example, if "svn switch" fails halfway through, or if you enter a command wrong). And the worst part is: if you ever get into a situation where some of your files are coming from one place, and some of them from another, the "svn status" will tell you that everything is normal. You'll need to do "svn info" on each file/directory to discover how weird things are. If "git status" tells you that things are normal, then you can trust that things really are normal.
  5. You have to tell SVN whenever you move or delete something. Git will just figure it out.
  6. Ignore semantics are easier in Git. If you ignore a pattern (such as *.pyc), it will be ignored for all subdirectories. (But if you really want to ignore something for just one directory, you can). With SVN, it seems that there is no easy way to ignore a pattern across all subdirectories.
  7. Another item involving ignore files. Git makes it possible to have "private" ignore settings (using the file .git/info/exclude), which won't affect anyone else.

(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
(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
(8) @Chris: You can do it explicitely: git mv and git rm. - R. Martinho Fernandes
(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
(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
I have faced problems #4, #6 and #7 with svn. +1 for pointing them out w.r.t. git. - Sushant
I don't understand how #3 and #5 are both true... it seems like me that the point of having an .svn in every folder would be to seamlessly move stuff, and with one central location it is much harder to track movements... - Dan
I think #5 is a perfect counterpoint to the "git is harder to learn than svn" argument. I have seen so many source control newbies get hamstrung by this. They svn add a file, do some more work, decide to remove the file and then everything blows up in their face when they run svn ci. - Sharpie
I for one don't care much about git being distributed. But it's exactly due to these small things, #3 and #5 in particular that I switched to git. - CodesInChaos
[+56] [2009-02-10 04:18:46] sebnow

" Why Git is Better than X [1]" outlines the various pros and cons of Git vs other SCMs.


  • Git tracks content rather than files
  • Branches are lightweight and merging is easy, and I mean really easy.
  • It's distributed, basically every repository is a branch. It's much easier to develop concurrently and collaboratively than with Subversion, in my opinion. It also makes offline development possible.
  • It doesn't impose any workflow, as seen on the above linked website [2], there are many workflows possible with Git. A Subversion-style workflow is easily mimicked.
  • Git repositories are much smaller in file size than Subversion repositories. There's only one ".git" directory, as opposed to dozens of ".svn" repositories (note Subversion 1.7 and higher now uses a single directory [3] like Git.)
  • The staging area is awesome, it allows you to see the changes you will commit, commit partial changes and do various other stuff.
  • Stashing is invaluable when you do "chaotic" development, or simply want to fix a bug while you're still working on something else (on a different branch).
  • You can rewrite history, which is great for preparing patch sets and fixing your mistakes (before you publish the commits)
  • … and a lot more.

There are some disadvantages:

  • There aren't many good GUIs for it yet. It's new and Subversion has been around for a lot longer, so this is natural as there are a few interfaces in development. Some good ones include TortoiseGit [4] and GitHub for Mac [5].
  • Partial checkouts/clones of repositories are not possible at the moment (I read that it's in development). However, there is submodule support. Git 1.7+ supports sparse checkouts [6].
  • It might be harder to learn, even though I did not find this to be the case (about a year ago). Git has recently improved its interface and is quite user friendly.

In the most simplistic usage, Subversion and Git are pretty much the same. There isn't much difference between:

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


git clone
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
does svn track changes accross files? - Seun Osewa
(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ć
[+54] [2008-08-03 22:44:26] ESV

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' talk is more constructive, more informative and more convincing. - bendin
(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. - schoetbi
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. - Tyler
@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
[+26] [2008-08-03 22:47:42] Karl Seguin

Well, it's distributed. Benchmarks indicate that it's considerably faster (given its distributed nature, operations like diffs and logs are all local so of course it's blazingly faster in this case), and working folders are smaller (which still blows my mind).

When you're working on subversion, or any other client/server revision control system, you essentially create working copies on your machine by checking-out revisions. This represents a snapshot in time of what the repository looks like. You update your working copy via updates, and you update the repository via commits.

With a distributed version control, you don't have a snapshot, but rather the entire codebase. Wanna do a diff with a 3 month old version? No problem, the 3 month old version is still on your computer. This doesn't only mean things are way faster, but if you're disconnected from your central server, you can still do many of the operations you're used to. In other words, you don't just have a snapshot of a given revision, but the entire codebase.

You'd think that Git would take up a bunch of space on your harddrive, but from a couple benchmarks I've seen, it actually takes less. Don't ask me how. I mean, it was built by Linus, he knows a thing or two about filesystems I guess.

(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
(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
[+22] [2008-09-04 11:06:59] Emmanuel Caradec

The main points I like about DVCS are those :

  1. You can commit broken things. It doesn't matter because other peoples won't see them until you publish. Publish time is different of commit time.
  2. Because of this you can commit more often.
  3. You can merge complete functionnality. This functionnality will have its own branch. All commits of this branch will be related to this functionnality. You can do it with a CVCS however with DVCS its the default.
  4. You can search your history (find when a function changed )
  5. You can undo a pull if someone screw up the main repository, you don't need to fix the errors. Just clear the merge.
  6. When you need a source control in any directory do : git init . and you can commit, undoing changes, etc...
  7. It's fast (even on Windows )

The main reason for a relatively big project is the improved communication created by the point 3. Others are nice bonuses.

I think point #1 intends to say "other people won't see them until you publish" (or "push"). - jackr
+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
[+15] [2008-10-02 13:05:58] Andre Bossard

The funny thing is: I host projects in Subversion Repos, but access them via the Git Clone command.

Please read Develop with Git on a Google Code Project [1]

Although Google Code natively speaks Subversion, you can easily use Git during development. Searching for "git svn" suggests this practice is widespread, and we too encourage you to experiment with it.

Using Git on a Svn Repository gives me benefits:

  1. I can work distributed on several machines, commiting and pulling from and to them
  2. I have a central backup/public svn repository for others to check out
  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
@Sam unless you happen to like git and/or dislike mercurial. - Tyler
[+11] [2009-10-13 07:01:50] si618

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
(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
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
(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
Non-programmers are already going to have problems with subversion anyway. It would be much better to give them an actual document publishing application which has version control than to use a svn-GUI. Why not write the documents in a wiki with revisions. There are even a few git powered wikis around which use git as the data storage. Programmers should have the best tool for the job, and that is git or Hg because of the freedom of workflow. - Benbob
(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
For example, I mean integration into Windows (TortoiseSVN) and Visual Studio (AnkhSVN). Do all developers like to go to the command line instead of a nice GUI or IDE? What I'm saying is that I don't think you can categorically state that git/Hg is the best tool for the job, because if people don't like the VCS client, they won't make use of the tool, no matter how much freedom it gives to your workflow. - si618
[+9] [2008-09-18 18:44:51] neu242

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 [1], and there are good explorer extensions available (like TurtoiseSVN). Other than that, I'll have to agree with Michael [2]: 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
[+8] [2008-08-22 15:24:44] swilliams

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
[+8] [2010-09-17 18:22:30] Elaine Murphy

David Richards WANdisco Blog on Subversion / GIT [1]

The emergence of GIT has brought with it a breed of DVCS fundamentalists – the ‘Gitterons’ – that think anything other than GIT is crap. The Gitterons seem to think software engineering happens on their own island and often forget that most organizations don’t employ senior software engineers exclusively. That’s ok but it’s not how the rest of the market thinks, and I am happy to prove it: GIT, at the last look had less than three per cent of the market while Subversion has in the region of five million users and about half of the overall market.

The problem we saw was that the Gitterons were firing (cheap) shots at Subversion. Tweets like “Subversion is so [slow/crappy/restrictive/doesn't smell good/looks at me in a funny way] and now I have GIT and [everything works in my life/my wife got pregnant/I got a girlfriend after 30 years of trying/I won six times running on the blackjack table]. You get the picture.


(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
(2) Ironically, Git was created specifically because software engineering doesn't happen on islands. This quote is moronic. - Ben Collins
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. - Benbob
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
[+7] [2008-08-09 03:22:14] ejunker

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.

[+6] [2008-08-03 23:38:05] Orion Edwards

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
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
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
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
[+6] [2008-08-22 15:19:57] Pat Notz

Easy Git [1] has a nice page comparing actual usage of Git and SVN [2] 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.)


[+5] [2008-08-03 23:08:23] jaredg

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
[+5] [2008-10-05 16:52:34] Mozammel

I like Git because it actually helps communication developer to developer on a medium to large team. As a distributed version control system, through its push/pull system, it helps developers to create a source code eco-system which helps to manage a large pool of developers working on a single project.

For example say you trust 5 developers and only pull codes from their repository. Each of those developers has their own trust network from where they pull codes. Thus the development is based on that trust fabric of developers where code responsibility is shared among the development community.

Of course there are other benefits which are mentioned in other answers here.

[+4] [2009-08-07 14:59:17] William Pursell

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
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
@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. - Tyler
[+4] [2010-07-27 15:40:33] inger

I think Subversion is fine.. until you start merging.. or doing anything complicated.. or doing anything Subversion thinks is complicated (like doing queries to find out which branches messed with a particular file, where a change actually comes from, detecting copy&pastes, etc)...

I disagree with the winning answer, saying the main benefit of GIT is offline work - it's certainly useful, but it's more like an extra for my use case. SVK can work offline too, still there is no question for me which one to invest my learning time in).

It's just that it's incredibly powerful and fast and, well -after getting used to the concepts - very useful (yes, in that sense: user friendly).

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


[+3] [2008-08-30 12:01:09] dbr

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)

[+3] [2010-02-10 22:54:35] Matt Hulse

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.

[+3] [2011-05-29 17:30:50] gtd

This is the wrong question to be asking. It's all too easy to focus on git's warts and formulate an argument about why subversion is ostensibly better, at least for some use cases. The fact that git was originally designed as a low-level version control construction set and has a baroque linux-developer-oriented interface makes it easier for the holy wars to gain traction and perceived legitimacy. Git proponents bang the drum with millions of workflow advantages, which svn guys proclaim unnecessary. Pretty soon the whole debate is framed as centralized vs distributed, which serves the interests of the enterprise svn tool community. These companies, which typically put out the most convincing articles about subversion's superiority in the enterprise, are dependent on the perceived insecurity of git and the enterprise-readiness of svn for the long-term success of their products.

But here's the problem: Subversion is an architectural dead-end.

Whereas you can take git and build a centralized subversion replacement quite easily, despite being around for more than twice as long svn has never been able to get even basic merge-tracking working anywhere near as well as it does in git. One basic reason for this is the design decision to make branches the same as directories. I don't know why they went this way originally, it certainly makes partial checkouts very simple. Unfortunately it also makes it impossible to track history properly. Now obviously you are supposed to use subversion repository layout conventions to separate branches from regular directories, and svn uses some heuristics to make things work for the daily use cases. But all this is just papering over a very poor and limiting low-level design decision. Being able to a do a repository-wise diff (rather than directory-wise diff) is basic and critical functionality for a version control system, and greatly simplifies the internals, making it possible to build smarter and useful features on top of it. You can see in the amount of effort that has been put into extending subversion, and yet how far behind it is from the current crop of modern VCSes in terms of fundamental operations like merge resolution.

Now here's my heart-felt and agnostic advice for anyone who still believes Subversion is good enough for the foreseeable future:

Subversion will never catch up to the newer breeds of VCSes that have learned from the mistakes of RCS and CVS; it is a technical impossibility unless they retool the repository model from the ground up, but then it wouldn't really be svn would it? Regardless of how much you think you don't the capabilities of a modern VCS, your ignorance will not protect you from the Subversion's pitfalls, many of which are situations that are impossible or easily resolved in other systems.

It is extremely rare that the technical inferiority of a solution is so clear-cut as it is with svn, certainly I would never state such an opinion about win-vs-linux or emacs-vs-vi, but in this case it is so clearcut, and source control is such a fundamental tool in the developer's arsenal, that I feel it must be stated unequivocally. Regardless of the requirement to use svn for organizational reasons, I implore all svn users not to let their logical mind construct a false belief that more modern VCSes are only useful for large open-source projects. Regardless of the nature of your development work, if you are a programmer, you will be a more effective programmer if you learn how to use better-designed VCSes, whether it be Git, Mercurial, Darcs, or many others.

[+2] [2009-10-13 13:14:45] devarni

Subversion is very easy to use. I have never found in the last years a problem or that something doesn't work as expected. Also there are many excellent GUI tools and the support for SVN integration is big.

With Git you get a more flexible VCS. You can use it the same way like SVN with a remote repository where you commit all changes. But you can also use it mostly offline and only push the changes from time to time to the remote repository. But Git is more complex and has a steeper learning curve. I found myself in the first time committing to wrong branches, creating branches indirectly or get error messages with not much informations about the mistake and where I must search with Google to get better informations. Some easy things like substitution of markers ($Id$) doesn't work but GIT has a very flexible filtering and hook mechanism to merge own scripts and so you get all things you need and more but it needs more time and reading of the documentation ;)

If you work mostly offline with your local repository you have no backup if something is lost on your local machine. With SVN you are mostly working with a remote repository which is also the same time your backup on another server... Git can work in the same way but this was not the main goal of Linus to have something like SVN2. It was designed for the Linux kernel developers and the needs of a distributed version control system.

Is Git better then SVN? Developers which needs only some version history and a backup mechanism have a good and easy life with SVN. Developers working often with branches, testing more versions at the same time or working mostly offline can benefit from the features of Git. There are some very useful features like stashing not found with SVN which can make the life easier. But on the other side not all people will need all features. So I cannot see the dead of SVN.

Git needs some better documentation and the error reporting must be more helpful. Also the existing useful GUIs are only rarely. This time I have only found 1 GUI for Linux with support of most Git features (git-cola). Eclipse integration is working but its not official released and there is no official update site (only some external update site with periodical builds from the trunk So the most preferred way to use Git this days is the command line.

[+2] [2009-10-13 13:36:01] zendar

Eric Sink [1] from SourceGear wrote series of articles on differences between distributed and nondistributed version controls systems. He compares pros and cons of most popular version control systems. Very interesting reading.
Articles can be found on his blog, [2]:


[+2] [2011-03-09 14:05:56] jotik

For people looking for a good Git GUI, Syntevo SmartGit [1] 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.


[+1] [2010-01-03 12:45:36] Dan Rosenstark

First, concurrent version control seems like an easy problem to solve. It's not at all. Anyway...

SVN is quite non-intuitive. Git is even worse. [sarcastic-speculation] This might be because developers, that like hard problems like concurrent version control, don't have much interest in making a good UI. [/sarcastic-speculation]

SVN supporters think they don't need a distributed version-control system. I thought that too. But now that we use Git exclusively, I'm a believer. Now version control works for me AND the team/project instead of just working for the project. When I need a branch, I branch. Sometimes it's a branch that has a corresponding branch on the server, and sometimes it does not. Not to mention all the other advantages that I'll have to go study up on (thanks in part to the arcane and absurd lack of UI that is a modern version control system).

[+1] [2010-02-10 16:29:29] user267751

Git in Windows is quite well supported now.

Check out GitExtensions =

and the manual for a better Windows Git experience.

[+1] [2010-02-10 18:51:32] user270537

I think it's fairly safe to say that amongst developers, the SVN Vs. Git argument has been raging for some time now, with everyone having their own view on which is better. This was even brought up in the of the questions during our Webinar on Subversion in 2010 and Beyond.

Hyrum Wright, our Director of Open Source and the President for the Subversion Corporation talks about the differences between Subversion and Git, along with other Distributed Version Control Systems (DVCS).

He also talks about the upcoming changes in Subversion, such as Working Copy Next Generation (WC-NG), which he believes will cause a number of Git users to convert back to Subversion.

Have a watch of his video and let us know what you think by either commenting on this blog, or by posting in our forums. Registration is simple and will only take a moment!

Obviously biased, as his tool is based on Subversion. Just saying. - Jakub Narębski
[+1] [2010-04-25 21:35:23] haknick

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 [1] which, from what I've seen so far, does not work so nicely and seamlessly in Git.


[+1] [2010-10-22 16:25:05] Adrian Smith

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