Why we use SCM systems
I'm watching a newly-minted co-op student dealing with her first encounter with Git, unhelpfully shepherded by a developer to whom everything below is already second nature, so deeply that the reasoning is hard to articulate. It is not going well.
I have the same problem, and it could be me trying to give someone an intro to Git off the top of my head, but it's not, today. For next time, here are my thoughts. They have shockingly little to do with Git.
- You're working on a software project.
- You know how to read and write code.
- You're human.
- You have end users or customers - people other than yourself who care about your code.
- Your project is going to take more than a few minutes to reach end of life.
The safety net
Having a record of past states and known-good states means that, when (WHEN) you write some code that doesn't work, and when (WHEN) you're stumped as to why, you can throw your broken code away and get to a working state again. It also helps with less-drastic solutions by letting you run comparisons between your broken code and working code, which helps narrow down whatever problem you've created for yourself.
(Aside: if you're in a shop that “doesn't use source control,” and for whatever insane reason you haven't already run screaming, this safety net is a good reason to use source control independently of the organization as a whole. Go on, it's easy; modern DSCM tools like Mercurial or Git make importing “external” trees pretty straightforward. Your future self thanks you.)
Having a record of past, released states means you can go back later and recover how your project has changed over time. Even if your commit practices are terrible, when (WHEN) your users complain that something stopped working a few months ago and they never bothered to mention it until now, you have some chance of finding out what caused the problem. Better practices around commit messages and other workflow-related artifacts improve your chances of finding out why, too.
Every SCM system and every release process is designed to help the humans in the loop agree on what, exactly, the software being released looks like and whether or not various releasability criteria have been met. It doesn't matter if you use rolling releases or carefully curate and tag every release after months of discussion, you still need to be able to point to a specific version of your project's source code and say “this will be our next release.”
SCM systems can help direct and contextualize that discussion by recording the way your project has changed during those discussion, whether that's part of development or a separate post-“freeze” release process.
Proposals and speculative development
Modern SCM systems (other than a handful of dismal early attempts) also help you propose and discuss changes. Distributed source control systems make this particularly easy, but even centralized systems can support workflows that record speculative development in version control. The ability to discuss specific changes and diffs, either within a speculative line of development or between a proposed feature and the mainline code base, is incredibly powerful.
The bottom line
It's about the people, not the tools, stupid. Explaining how Git works to someone who doesn't have a good grasp on the relationship between source control tools and long-term, collaborative software development won't help.