Version control: the questions we get asked most

We end up explaining this on discovery calls often enough that it deserved writing down. The questions about version control that come up most often on our calls.

The question is rarely whether something can be built, but what it costs to keep running afterwards. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Do we need to care about this?

Small commits with clear messages are a gift to future you. Small and consistent beats large and occasional here. Budget a little time for it every quarter and it never becomes a project of its own.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

If it is not in version control, it does not exist. There is a version of this that is over-engineered, and it is worth avoiding. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The short version

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.