Subversion vs. Git

If you don’t like making up your own mind and prefer to ride the wave of whatever happens to be popular right now, you might think that, when it comes to source control, there are two choices: Subversion and Git, and no middle ground.

(Yes, there are others, but I’m trying to keep this simple.)

This is just not true. Daniel Jalkut addresses this from one perspective in Zealotry For Good And Evil, but I’d like to add to his arguments from the perspective of a single developer or small team.

Subversion works in mostly the same way that source control has worked for decades, so for anyone that’s been in the industry for a while, there are few surprises. This means that, for the most part, the source control system stays out of the way and does the jobs we need it to.

Git was built to solve a different problem: how to provide source control to a globally distributed team, where one centralized, master repository was viewed as a bug, not a feature. Individuals or small teams don’t have this problem.

Fundamentally, though, rather than having arguments about which source control system is “better,” recognize that they are tools, with different strengths, and use the one that feels the best to you and lets you get your work done efficiently.

Personally, I’m experimenting with using Git as a means to version controlling projects for clients where I expect to make changes in many places, but I don’t expect the project to last very long. For these, it seems more trouble than it’s worth to carve out a place in my central Subversion repository, especially because I won’t need to provide outside access to it. Git’s placement of the repository within my working tree is a feature here.