5.2 Version Control As Team Memory

Version control is more than backup. It is the memory of how a system changed, who reviewed it, what tradeoffs were accepted, and how to recover when a change is wrong.

Git stores snapshots. A good team uses those snapshots to tell a coherent engineering story.

Commits as units of reasoning

A commit should usually be:

• Focused: one logical reason to change.
• Reviewable: small enough to understand.
• Reversible: can be rolled back without dragging unrelated work.
• Explained: the message says why, not only what.

Weak commit message: update stuff

Better: Guard invoice export behind report permission

Best body: explain the user/security reason and mention tests or migration notes.

Branching and pull requests

Branches isolate work. Pull requests create a reviewable conversation around a change.

Good PRs usually include:

• Problem statement.
• Summary of approach.
• Risk areas.
• Testing evidence.
• Screenshots or examples when behavior is visible.
• Rollout or migration notes when production risk exists.

Merge is a product decision too

Merging is not just a Git event. It changes what the team now owns. If a change is hard to roll back, hard to observe, or hard to explain, the PR should make that visible before merge.

Version control gives you history. Engineering discipline makes that history useful.