A Force-Push Disaster at 2 a.m. Produced a Git Workflow That Makes Rollback a Two-Command Job
Teams that lack a mechanical branch discipline discover the cost only during a crisis — a force-push that erases history, a release with no known good commit to roll back to, or a SNAPSHOT dependency that makes a production artifact unreproducible. This spec removes those failure modes with rules simple enough to fit on a single printed sheet.
The workflow treats master and develop as the only permanent branches; every feature, sprint, release, and hotfix is a temporary branch with a fixed origin and destination. Squash merges keep personal work clean, while `--no-ff` merges leave visible iteration milestones. Version numbers change only when cutting a release or hotfix — never during daily development — and SNAPSHOT dependencies are banned from master and production.
A full walkthrough follows an e-commerce v2.1.0 iteration from sprint creation through QA, RC candidate images, blue-green deployment, and a hotfix for a production payment timeout. The same blue-green setup enables a two-command, zero-downtime rollback by flipping an nginx config line.
Five quick-reference tables and five hard rules — no force-push to shared branches, no direct commits to master or develop, no merges without review, no SNAPSHOTs in master, and mandatory team notification after any rollback — turn the spec into something a team can print and tape to the wall.
Most Git disasters are not skill gaps but missing constraints — branch protection, mandatory reviews, and fixed merge strategies remove the degrees of freedom that cause them.
The distinction between Squash and `--no-ff` is a useful heuristic that many teams never articulate: squash individual work to hide noise, preserve merge commits for public milestones to keep history navigable.
Delaying the version number change until the release branch is cut eliminates a common source of confusion where developers change it mid-sprint and lose track of which artifact matches which code.
Banning SNAPSHOT dependencies from master is a reproducibility rule that teams often learn only after a production incident where no one can rebuild the exact deployed artifact.