VCS practices over features
I've often heard people I know and respect say that git is leaps and bounds better than Subversion . I've been a relatively early adopter of git, it's been my VCS of choice for almost two years now. Even though I find it superior to most of the competition I struggle to justify the "leaps and bounds" claim and would rather more modestly call it "a step forward".
This is probably due to the practices we find benefit our development process. Git puts great emphasis on branching, something we generally tend to avoid (to clarify, I'm not referring to local branching). We concentrate on feedback based on the usage of our applications. This means that we strive to commit as often as possible and, most importantly, deploy to production at a constant rate. Grossly simplified, the process is: identify a small coherent feature, build it, commit it to the master branch and deploy. No part of the codebase is owned by a subdivision of the team, everyone works on everything.
By far the most popular git commands we issue are
git pull,
git add
and
git push,
not that different to
svn update
and
svn commit.
When I first started using git I was wondering if I had developed a fear of branching because of Subversion's inefficiencies in that area. In reality, I think that an environment where every developer constantly has an up to date understanding of the codebase and especially a current grasp of the design and overall vision will always be more efficient than working remotely and having merge checkpoints, no matter how cleverly the VCS handles branching. This is why I think a faster, distributed, superior at merging VCS is not something more dramatic than a desirable step forward.