Before we get started into why use scm, better to start with the question of what it is.
So what is SCM?
Some people call SCM software configuration management, which is not what I’m talking about here, although SCM as I know it is a small part of software configuration management. SCM for me is what it is for many other programmers out there: source code management. Specifically, versioning.
That means that an SCM system keeps track of different versions of my code, and can tell me exactly when I wrote each line of code, and even roll back changes in case I was drunk coding (not something I advocate).
So why use it?
3 reasons:
- Keep track of your development efforts, which can translate into savings when you need to figure out when you introduced a bug. It happens to all of us.
- If you’ve ever worked on a project with someone else, you probably sent copies over email. Now imagine that you made changes to a file, and so did your partner. Try merging those changes by hand. Probably took you a long time, and was painful. On the other hand, SCM does this almost instantly (except where you need to decide which changes to merge, in the case of the exact same lines being changed in both branches).
- Being familiar with an SCM is a big bonus for your resume. It indicates that you’re ready and willing to work on large projects, and collaborate as part of a team.
Types of SCM
Now that you’ve decided to use SCM, the question is which one do you start using.
There are many options, each with their arguments in favor or against. I’m going to try and keep this apolitical, but I will say that I’ve been using Git, and I quite like it.
Centralized
- CVS (hella old school, very few people use this if they have a choice)
- SVN - considered to be CVS done right. Linus thinks otherwise.
- Perforce
Distributed
- Git
- Mercurial
- Bazaar
- BitKeeper