In software engineering, source control is everything.
If you manage programmers, work with programmers, depend on what they do, or are just getting started as a software engineer, and you don’t already understand this, then you’re missing out on half the conversation. The aim of this article is to help you understand the other half.
If are a programmer, and you already know all this, there’s some points about branch management later on that you might find useful.
So here’s the thing - writing some code to do a job is pretty easy. What’s hard is writing code that:
-
won’t break anything else (including performance)
-
you (or someone else) can still understand three months later
-
can be extended and reused to make your next job simpler
-
behaves in a predictable way
The first job of a source control system is to make it possible to reproduce a build: once a release has gone to a customer, how do you know which precise versions of which precise lines of code went into that build? Source control is how. There’s a bunch of methodologies that go with that, like tagging – but this is better covered in an article on release management.