Trunk-based development
Everyone merges small changes into main every day instead of nursing feature branches for weeks.
See it
What it is
One shared branch (main, the trunk) is always releasable, and everyone merges into it at least daily. Branches still exist, they just live hours to a couple of days, not weeks. The bet: many tiny merges hurt less in total than one giant merge, because conflicts are found while the code is still fresh in someone's head.
The thing that makes it work is decoupling merge from release. Half-finished work goes to main behind a feature flag, dark launched and off by default, so 'merged' stops meaning 'live'. Pair that with required status checks on main, small pull requests, and fast CI, or the trunk turns into a queue of broken builds.
Misconception: trunk-based development is not 'push straight to main with no review'. It is the opposite of long-lived branches, not the opposite of discipline. Where it genuinely fights you: releases that need long QA windows, app-store review cycles, or supported old versions, which is why teams still cut short-lived release branches off the trunk and cherry-pick hotfixes into them.
Ask AI for it
Restructure our git workflow to trunk-based development and write it up as a CONTRIBUTING section. Rules: main is always releasable; branches live under 48 hours and are named type/short-description; pull requests stay under roughly 400 changed lines; every unfinished feature ships behind a feature flag that defaults to off; no long-lived develop branch. Add the GitHub branch protection settings (required status checks, one approving review, linear history, delete branch on merge) and describe how to cut a short-lived release branch and cherry-pick a hotfix onto it.