Hacker News new | comments | show | ask | jobs | submit login

I started using Git as a filesystem long before I started using it as an SCM, so I never really went through the 'choosing' process, however, from the people that I talk to about this, Gits popularity tends to be because of the cheap local branching. There is no other system out there that is nearly as good at this as Git. Baz, Merc, Darcs, SVN, Perforce, CVS - these are all patch or changeset based systems where branching is tacked on in a complicated manner. Even the Hg Book recommends cloning for real branches over the local branch system it has.

This functionality is truly a deal-breaker for most people, and completely changes the way you develop and think about development. There are very few people I've ever met that have learned the git branching system (which is not hard to learn) and then went back to another DSCM. The fact is that none of these other systems are nearly as good at this as Git is because they way they think about history (patches/changesets vs DAG snapshots) is simply not well suited for it.

That, plus the fact that Git usability has improved so much recently that it's hard to argue that any of them are really easier to learn, and super powerful features for more advanced users like the staging area (which I also would hate to live without) I think explain why Git is becoming more popular at such a fast rate.

It's not that the other systems aren't getting love, but that it's getting harder to argue against Git and while all of them share largely the same basic data storage mechanism, Git's is entirely different, so while Git can always make the UI better (and it constantly is), the other systems are having a really hard time trying to catch up with the features Git had from day one.

Others may disagree with me, and will normally argue that it's just a fanboy bandwagon koolaid whatever, but I think that the real reason is that when most people learn Git fundamentals they realize that they become more efficient and none of the other systems can do that for them in the same way.

Branching was by and far the winning feature for me. SVN made branching and tagging very time consuming (making a full copy, to the server nonetheless). Merging correctly on SVN? Never the first time! Usually took 2-3 tries before you got the syntax correct. Dry-run never really helped either. SVN merging was leagues harder to learn then the entirety of git for me.

The simplicity of making a local directory versioned is wonderful too. It has use far beyond code. I can quickly version my documents folder, easily recover from mistakes, and with one little push I have a backup! To even try to do this in SVN was another headache, and it required an SVN server somewhere... with git I don't have to push if I don't want to.


Using lots of small, short-lived branches conditions you to think about your development in a new way: instead of a single, linear development process, you have a number of parallel development efforts, and you know that only some of them will be successful.

By taking full advantage of fast branch and merge operations, you train yourself to experiment with many possible implementations of the same idea, without completely losing the history of your trials.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact