Source Control as Production

A commit is not history; it is a candidate for production state. Branching models, protected branches and required checks as delivery infrastructure rather than team preference.

Source Control as Production Infrastructure

When merging triggers delivery, the repository stops being a record of what happened and becomes the control plane for what production is.

Q · If a merge can change production, what does that make the repository, and what does it owe you?
Git Workflows

Branching models are delivery constraints, not team preferences — and there is no universal winner, because they optimise for different release realities.

Q · Which branching model fits, given what you ship, to whom, and how often?
Trunk-Based Development

Small changes, integrated into one mainline at least daily, with main kept releasable at all times — which is a set of demanding requirements, not a branch naming convention.

Q · What does it actually take to keep one mainline releasable while everybody integrates into it every day?
Long-Lived Branches

Divergence has a cost that grows superlinearly with time, and the expensive part — semantic conflict — is invisible to every merge tool.

Q · What does a branch actually cost per day it stays open, and when is that cost worth paying?
Protected Branches

Rules on the branch pointer that delivery reads from — enforced server-side, because anything enforced on the developer's machine is advice.

Q · What has to be true about the branch your pipeline deploys from, and where can that be enforced?
Required Checks

Automated checks bound to a branch as a merge condition — useful exactly to the extent that they ran on the right code, mean something, and are trusted.

Q · What should be required before a merge, and what makes a required check worth its latency?