Unless you’re a software developer, you’ve probably never heard of Git. If I told you it’s a source code version control system, you’re might then think, “who cares?”

Occasionally, a tool comes along that quietly but powerfully changes the way things are done. Git is one of those tools. Developed out of necessity by Linus Torvalds in 2005 to host the Linux kernel, it’s recently exploded in popularity.

For all of its features, Git’s real power is enabling distributed, non-linear development. Because branches are effectively “free”, everything’s done in branches. Developers typically work in their own branches. If a developer is fixing a bug, she might make a new branch, fix, test and commit, then merge that back into a working branch (or the main one).

In contrast, with systems like Subversion, there tends to be much less branching. Developers end up “huddling” around branches, and having to spend much more time coordinating commits. The usual result is that commits are larger and less frequent, which makes merging significantly more difficult.

With Git, developers make small, frequent commits to their own working branches, then they merge that branch into the main one. Often, the merging can be automated: the merger has a much better chance of success with 10 small commits than one big one. Also, Git enables ad hoc sub-projects: two developers working in the same area can merge between themselves, then when done, offer up the combined branch to merge into the main project.

But it’s not enough to just start using Git — if your team uses Git like they use Subversion, you won’t be getting the benefit. You’ve also got to change your development workflows.

Why aren’t you using Git for your project?