git-collaboration-workflowslisted

# Git Collaboration Workflows Git workflow debates are proxy wars over one variable: **how often you ship**. Choose the branching model from your deploy cadence, enforce it with branch protection instead of vigilance, and keep PRs small enough to review honestly. Deep detail in `references/`; protection settings and a PR-review playbook in `examples/`; `scripts/check-branch-hygiene.mjs` audits a repo's local hygiene. ## Choosing the branching model | You deploy… | Model | Shape | |---|---|---| | Continuously (SaaS default) | **Trunk-based** | Short-lived branches (<2 days) → main; release = deploy main; flags hide unfinished work | | On a cadence (mobile, desktop) | Trunk + **release branches** | Cut `release/1.24` from main; only cherry-picked fixes land on it; tag ships | | Multiple supported majors (enterprise, on-prem) | Trunk + long-lived release lines | Fix on main first, cherry-pick back (never the reverse) | Full git-flow (develop + feature + release + hotfix branches) earns its complexity only in the third row — adopted by SaaS teams it mostly adds merge ceremony and delays integration. The deciding question is never taste; it's "what do we support in production simultaneously?" ```text trunk-based: main ──●──●──●──●──► release = deploy latest green main cadence: main ──●──●──●──► release/1.24 ──●(cp)──tag 1.24.1 hotfix: branch from the SHIPPED TAG, fix, tag — then forward-port to main SAME DAY ``` Mechanics of each and t