git notes main page | gitolite main page | license
IMPORTANT NOTE:
although this page has a "gitolite.com" URL, this is not about gitolite.
That's just an artifact of "sitaramc.github.com" being translated to
"gitolite.com" and so ALL my git related stuff gets carried over.
Gitolite documentation has another /gitolite in the URL, so
you can tell. My apologies for this confusion.
The official comparison is here. There is also a Git - SVN crash course.
Lots of SVN info is scattered in a few other files in this directory; eventually it should all be pulled into this file.
^^as Churchill said, so much to do, and so little time in which to do it… (sigh)^^
What follows is my understanding of the SVN scenario, from various sources. I personally have used SVN only briefly. If there are errors in the SVN part of this description please let me know.
Git’s advantages over SVN (all of them affect productivity and/or maintainability, indicated in parens as P or M) are:
(P) handles merges automatically (in fact SVN doesn’t really “handle” merges; merge history must be manually recorded and managed, and it’s almost impossible to have 2 branches merging regularly in SVN without a lot of pain for the integration team)
(M) handles file renames correctly; helps in refactoring (in SVN, a rename is handled as a delete of the old file plus an add of the new file, and it is only tracked as such if you explicitly told svn about the rename. That is not the only brittle aspect; renames and merges don’t mix well, apparently. Also, SVN may become confused when files are modified and renamed in the same commit.)
(P, M) devs can create local branches without polluting the central server – experimental features can be developed and tested “on the side”, with full revision control and granular commits. If the experiment worked, you bring it into the main repo (without losing the individual commits), otherwise you toss it. In SVN, a successful side project is forced to enter the main project as one large chunk of code, which seriously affects future maintainability.
(P, M) devs make lots of small commits instead of one humongous commit – much easier for code review, debugging, cherry-picking, and merging with other changes. Merge-conflict resolution happens on much smaller units instead of one huge chunk of code dumped on the repo! In SVN, every commit goes to the server, forcing commits to be large and monolithic, in turn causing every merge to be a serious exercise rather than a couple of minutes work.
(P) common VCS operations do not need network or server access, and are blazingly fast. SVN and other VCSs may take so long that a developer who is, say, trying to trace the changes that caused a bug may feel it’s easier to go through the code himself than run a ‘diff’ against the last known good version! That is, these VCSs have the tools but it’s a pain to use them!
Git does a lot of things better than any other VCS:
(P) branching/merging is so bad in most other VCSs that lots of projects forgo all the advantages of parallel development! Or they have to have a separate “merge team”, and they freeze development for a couple of days to do the merge. With git, merges (and therefore, merge conflicts, if any) are (i) handled by the developer closest to the merged code, not an upstream integrator who probably doesn’t know the new code well, and (ii) processed in many small chunks instead of one large chunk of code.
(M) git doesn’t track files, it tracks content. So if a piece of code moved from one source file to another, and you look at the history of that file visually, git will tell you that these lines came from that file over there, and it’ll also tell you the history of those lines before they came here. This is way beyond what any other VCS can imagine doing, and is a real lifesaver for someone who picks up a complex project for maintenance or a new team member is trying to understand the existing project.
When you, as a developer, have made a fair number of changes on your workstation, and wish to commit these to the SVN repo, you do an ‘svn update’. This brings in the latest changes from the server.
Unfortunately, if the other developers have also been very active, there could be a lot of new/changed code. All of those changes, in one fell swoop, are now merged into your working copy, so conflicts are very likely.
Worse, the ‘svn update’ has managed to lose the separation between your local changes and the updates that came from the server. You now have exactly one chance to resolve those conflicts and commit the result. And you’d better do it fast – before the upstream tree changes again!
[This is when an SVN newbie will realise he should have backed up his current source tree using tar or zip ;-)]
With git, you would not do the git pull while you still have uncommitted changes in your local repository. This is a distributed VCS, so you have a local repository to take care of all that.
So just commit all your changes locally, and then do a git pull!
Of course this will have the same conflicts as in SVN and you still have to do a manual conflict resolution, but:
git pull --rebase, (which is closer to what SVN does actually), then git will apply your local changes one commit at a time instead of the whole thing in one shot, making the conflict resolution also go in small, easily digestible chunks.git pull or git pull --rebase again.^^Basic idea from a post by Junio at https://article.gmane.org/gmane.comp.version-control.git/110671^^
When you do an ‘svn checkout’, you get a working copy of the revision you checked out, plus svn saves away an extra copy of the same stuff. This allows you to do things like see what you changed with respect to the checked out version.
But if you need a diff between your copy and some other version, you need network access. If you need a diff between two checked-in revisions, again you need network access.
When you do a git clone, however, git stores the complete history of all the branches that the parent repository has! So the only time you now need network access is when you want to update the server, nothing else.
This might make you think git’s repositories are huge! Far from it; here’s an example that uses the Mozilla repository, with full history from 1998 or so:
That’s a ratio of almost 20:1 in size over SVN.