GitHub Flow and Trunk-Based

Updated

October 30, 2026

GitHub Flow and Trunk-Based Development

After this page you can contrast a short-lived PR branch with committing to main behind flags.

GitHub Flow (as a Git topology)

main          always deployable
feat/…        branched from main, opened as a PR, merged, deleted

There is no long-lived develop. Production is main (or a tag on it). CI on the PR is the gate.

 GitHub Flow

 main     A ← B ← C ← M          always deployable
               ↖     ↗
 feat/ping      D ← E            PR, then delete

git switch main
git pull --ff-only
git switch -c feat/ping-json
# commits, push, PR, merge on the forge
git switch main
git pull --ff-only
git branch -d feat/ping-json

The name “GitHub Flow” is a topology. You can do it on Forgejo or GitLab. The forge UI is a PR/MR; Git is short-lived branches off main.

Trunk-based

Engineers commit to main (the trunk) at least daily, often several times a day. Features that are not ready stay dark behind a flag (next page). Release branches, if any, are cut from main and live days, not months.

 trunk-based

 main     A ← B ← C ← D ← E ← F     tiny commits, flags hide unfinished work
                     ╲
                      release/1.2   short-lived, if you even cut one

git switch main
# small commit
git pull --rebase
git push

Feature branches, when used, last hours. Rebase onto main before merge. --ff-only after a rebase is the usual integrate.

Compare

	Git Flow	GitHub Flow	Trunk-based
Long-lived lines	`main` + `develop`	`main`	`main`
Feature lifetime	Days–weeks	Hours–days	Hours or a flag
Release	`release/*` branch	Tag / deploy `main`	Tag / short `release/*`
Fits	Multi-version products	Web apps, desk tools	High-CI teams

desk-api in this book defaults to GitHub Flow topology: short feat/ branches, main deployable. Trunk-based is the same graph with even shorter branches.

Enforcement (required reviews, required checks) is chapter 31. The next page is flags, which make trunk-based possible.