Branching strategies

Git doesn't impose a workflow; teams agree on one. The main families:

Trunk-based development: everyone integrates into main (the trunk) at least daily, via very short-lived branches or directly. Unfinished features hide behind feature flags rather than living on long branches. It needs good automated tests and CI, and it minimizes merge pain because nothing diverges for long. It is the norm for teams practising continuous delivery.

GitHub flow: main is always deployable; every change is a branch plus pull request; after review and green CI it merges and deploys. Essentially trunk-based with PRs. A good default for web services and most teams.

Git flow: long-lived develop and main branches, plus feature/*, release/* and hotfix/* branches with prescribed merges between them. It suits software that ships numbered versions on a schedule and must support several in parallel, but it adds ceremony and long-lived divergence. Its own author has noted it is overkill for continuously delivered web apps.

Release branches combine with any of these: cut release/2.4 from main at release time, stabilise and patch it (cherry-picking fixes from main), and tag versions on it.

How to choose:

• Deploy continuously? Trunk-based or GitHub flow.
• Maintain multiple shipped versions (mobile apps, libraries, on-prem)? Add release branches, or Git flow.
• Whatever you choose, keep branches short-lived, protect main (required reviews and checks), and pick one PR merge style.

The strongest predictor of merge pain is branch lifetime, not the strategy's name.