No develop branch. No release branches. Everything starts from main and returns to it.
Why "short" is the whole point
A branch that lives a day diverges from main by a day's work.
A branch that lives three weeks diverges by three weeks — and every conflict you eventually hit was created by that gap.
Conflict pain scales with branch age. Not with team size, not with code complexity. Age.
5.2
Keeping current
Two ways, both fine
rebase onto main
Linear history. Rewrites your commits — new hashes.
git fetch
git rebase origin/main
merge main in
Adds a merge commit. Rewrites nothing.
git fetch
git merge origin/main
Trunk only ever receives squashed commits, so whatever shape your branch has, main gets one commit either way.
Our rule
Commandment 07
Keep your branch current with main. Rebase if you haven't shared it, merge if you have.
Not pushed yet? Rebase freely — it's yours.
Already pushed, or someone else is on it? Merge, and skip the force push entirely.
5.3
Pull requests
What actually lands on main
Four commits of yours become one on main. Its message comes from the PR title and description — not from your commits.
Write the description for the future
Commandment 10
The PR description is the permanent record. Write it for whoever debugs this in a year.
Explain why, not what — the diff already says what. Link the ticket. Note anything surprising.
Branch commit messages still matter, but for the reviewer, not for history.
Size is the reviewer's whole experience
Commandment 11
Keep PRs small enough to review in one sitting. If a reviewer can't hold it in their head, they should reject it and ask for smaller pieces.
A 40-file PR can't get 40 files of scrutiny. The right response isn't a scroll and an approve — it's sending it back to be split. Bouncing an oversized PR is doing the review, not dodging it.
Ownership
Commandment 12
You opened it, you own it. Chase the reviewers, keep it current, merge it.
A PR waiting on nobody in particular is the author's problem. Reviewers have their own work; a nudge is not rude.
Stale PRs are pure cost — they rot, they conflict, and they get merged unread out of guilt.
After the merge
The squashed commit on main is not a descendant of your branch's commits. It's a brand new commit containing the same changes.
So if you keep working on that branch, git sees your old commits as unmerged work — and tries to apply them again. Phantom conflicts, duplicated changes.
Commandment 13
After a squash merge, delete the branch and re-branch from main.
5.4
Our conventions
Let's write this down together
Question
Our answer
Branch naming
?
Expected branch lifetime
?
Rebase or merge to stay current
?
When is force push acceptable
?
PR size we aim for
?
How many reviewers
?
How long before nudging
?
Who merges
?
Where we got to
Git gives you mechanisms. We chose the policy.
Trunk-based, short branches, squash merge, small PRs, authors own them.
All of it is ours to change. If a rule stops making sense, bring it up — but change it deliberately, together, rather than quietly working around it.