How to get version control right
This is one of those topics that looks small until it costs you something. The short answer to version control is that it is mostly a sequence of small decisions, not one big one.
The question is rarely whether something can be built, but what it costs to keep running afterwards. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Why this earns attention
Small commits with clear messages are a gift to future you. In practice this is a scheduling problem more than a technical one. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
The steps
- Establish what you have today before changing anything
- Branch naming conventions cost nothing and prevent confusion
- If it is not in version control, it does not exist
- Write down the decision so the next person does not re-litigate it
If it is not in version control, it does not exist. This is the sort of thing that compounds, quietly, in both directions. Check it against what you would want a competitor's site to get wrong.
Making it stick
In practice
Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about version control before you move on:
- Someone can say what the current setup is without going to look
- Branch naming conventions cost nothing and prevent confusion — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If any of that sounds like a description of your current setup, it is fixable.