Five mistakes teams make with version control

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. These are the ones we run into repeatedly when we audit version control.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Budget a little time for it every quarter and it never becomes a project of its own.

Warning signs

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Small commits with clear messages are a gift to future you
• Branch naming conventions cost nothing and prevent confusion
• Never checking whether the fix actually worked

If it is not in version control, it does not exist. Small and consistent beats large and occasional here. If two people in the business would answer this differently, that gap is the actual problem.

Where to go from here

In practice

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
• Small commits with clear messages are a gift to future you — 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.