Git is Not a New Subversion
Table of Contents
Basing the decision to buy a car solely on horsepower can leave you with a tank in your garage. Not a very practical "car".
Now don't get me wrong: Git has plenty of horsepower, but this should not be the reason to use it in favor of Subversion or any other VCS.
Git isn't just a "new Subversion" that is faster, offline-capable, and somehow "cooler". The interesting parts about Git are where it's completely different from Subversion. These are the parts that change the way you develop software.
Branching
Yes: Git hasn't invented the concept of "branches". But it's the first system that was deliberately built around this concept. Only when branching becomes as fast & easy as it is in Git will you start to use it extensively. And that's exactly how you should use it: for every new feature, for every bugfix, for every experiment and proof of concept.
Using branches heavily in your development can make you a better programmer like few other habits can. The reason for this is that it helps you keep order in your project - because branches keep different contexts (features, bugfixes, etc.) separate from each other.
Without using branches, code from different contexts quickly mixes up. This makes it harder:
- for team members to understand what's going on (because they need to untangle which code is relevant for them and which isn't)
- to roll back code that causes problems (because it's mingled with other code that you will then need to roll back, too)
- to make useful experiments (because it's hard to get experimental code out if it proves you finally can't or don't want to implement it)
It's vital for such an important feature like branching to be easy and painless. Otherwise, developers (and even more so designers, copy writers, etc.) won't use it as extensively as they (undoubtedly) should.
Granular Commits
Here's a golden rule of version control (independent of the system you're using): A commit should only wrap changes that belong to the same topic. A "topic" might be a bugfix or a part of a feature.
In contrast, mixing up a little bit from feature X, the code for bugfix #324, and a function for feature Y in a single commit is a recipe for chaos. A developer that works solely on feature X will then have to inspect that whole, bloated commit and figure out what's relevant for him.
But for granular commits to happen, you need a system that supports you in this noble endeavour. Git does this in a couple of ways:
a) The Staging Area
In Git, a commit is carefully crafted: you have to decide which changes exactly you want in the next commit by adding them to the so-called "Staging Area". This doesn't stop at the file level: graphical interfaces like Tower allow you to inspect a changed file and simply select the individual lines you want to include in the next commit. This allows you to create very granular commits.
b) The Stash
In your day-to-day work, you often have to switch contexts due to interruptions, new priorities, or due dates. E.g. when an urgent bug report comes in - while you're in the middle of feature X.
What should you do with the unfinished work in progress? Make a copy of your working directory? Not the most elegant solution... Commit the half-done stuff? Absolutely not an elegant solution!
Git's "Stash" feature works as a clipboard that takes all your current local changes and saves them away, temporarily. Later, after solving that bug and returning to this context, you can simply restore these changes and continue where you left off.
It's not About Horsepower
Switching to Git is a great thing to do. But not as a faster, over-hyped replacement for Subversion. Instead, consider switching for the right reasons: because it might improve your project's quality and your abilities as a programmer.
