Monday, November 4, 2013

I've been using Subversion for a few years and after using SourceSafe, I just love Subversion. Combined with TortoiseSVN, 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.
How does Git improve upon Subversion?
Let's say that if you are on Windows, installing git using recommended msysgit version will take you 1300 MB of disk space. –  sorin Jul 21 '10 at 7:03
That's interesting given that the installer has a size of 12 MiB. Must be a really great compression algorithm. –  Philipp Jul 21 '10 at 13:07
@Sorin: If you are using msysGit installer, you are installing whole development toolchain for working ongit. Use "Git" installer, and not "msysGit" installer. I am sure it is much less than 1.3 GB... unless you use filesystem with very large clusters, and no packing of small files (FAT on large partitions). –  Jakub NarębskiJul 21 '10 at 13:13
Thanks, I found this few hours ago - I did not know that the netinstall of msysgit is in fact the development environment for msysgit. –  sorin Jul 21 '10 at 15:54
My Git- folder has 158MB, maybe you added too many files? –  IAdapter Jul 25 '10 at 16:40
show 7 more comments

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

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

30 Answers

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.
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
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
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
@Michael Stum - You've obviously never driven a Ferrari. :) –  Dana Holt Jun 2 '09 at 17:47
About these Ferrari comments... A straight answer, please... If I switch from svn to git, will it impress women? Will people think I'm rich and cool? Or... when I go on about it, will everyone think I'm even more of a gigantic dork than they do already? –  Steve314 Mar 6 '10 at 1:27
show 28 more comments
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, 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)
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
+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! –  Si. Mar 23 '09 at 16:42
I'm SVN user, but - try this: –  DiGi Jun 22 '09 at 12:35
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
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
show 4 more comments
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 allsubdirectories. (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.
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
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
@Chris: You can do it explicitely: git mv and git rm. –  R. Martinho Fernandes Sep 10 '09 at 10:57
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. –  Si. Oct 13 '09 at 6:05
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
show 6 more comments
"Why Git is Better than X" 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, 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 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 (beforeyou 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 TortoiseGitand GitHub for Mac.
  • 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.
  • 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.
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
@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
Google Tech Talk: Linus Torvalds on git
The Git Wiki's comparison page
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 Nov 10 '08 at 7:44
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 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
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.
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
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 :
  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 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
The funny thing is: I host projects in Subversion Repos, but access them via the Git Clone command.
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
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

No comments: