Git chaos is the main reason teams “cannot ship on Friday”. A simple branching and release policy prevents half of production incidents before deploy.
Trunk-based vs GitFlow
For frequent releases (SaaS, iGaming, marketplaces), trunk-based is enough: short feature branches, PR merge to main, release tag.
GitFlow fits multiple on-prem versions with long support. For cloud products it often adds merge noise and delay.
- main/master — always deployable
- feature/* — lives max 2–3 days
- release/* — fixes only before tag
- hotfix/* — from production tag, backport to main
Semver and tags
MAJOR.MINOR.PATCH for breaking / features / fixes. Tags v1.4.2 tie to CHANGELOG and CI artifacts.
Every prod deploy must be reproducible: commit SHA + docker image digest in release notes.
Protected branches and PRs
- No direct push to main
- CI required (lint, test, build)
- At least one approval; two for critical modules
- Pick squash or merge commits — one policy
Common mistakes
- Long-lived feature branches → week-long conflicts
- Hotfix on prod only, not main → regression next release
- No link between tag and DB migrations
Checklist
- Branching policy documented in README
- CI blocks merge on red tests
- Release checklist: migrations, flags, rollback
- One-page hotfix playbook
If releases still stall
- List open branches older than 3 days — close or rebase
- Ensure CI on main is green and blocks merge
- Run a practice hotfix: tag → fix → backport → tag
- Put the release checklist in README, not chat