A practical checklist for version control

Teams tend to reach for this after something has already gone wrong. Run through this the next time version control comes up.

The question is rarely whether something can be built, but what it costs to keep running afterwards. If it only works because one person remembers to do something, it does not work yet.

The checklist

• Small commits with clear messages are a gift to future you
• Branch naming conventions cost nothing and prevent confusion
• If it is not in version control, it does not exist
• Someone is named as the owner
• There is a date to review it again

The reason this keeps coming up

Small commits with clear messages are a gift to future you. The cost of getting this wrong is rarely visible on the day it happens. It rarely shows up as a line item, which is exactly why it slips.

How to tell if yours is fine

Most development decisions are really maintenance decisions wearing a different hat. 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

Most of the value here comes from doing the first two things, not all of them.