GitHub Flow

main always deployable, short branches per change, Pull Request and deploy after merge.

Context

Web products or SaaS with continuous deployment and a single production environment. The simplest option that works for most small and medium teams.

Solution

main is always deployable.
For each change, create a descriptively named branch from main.
Commit and open a Pull Request early.
After review and green CI, merge into main.
Deploy from main (ideally automatically).

BASH

git switch -c feature/invoice-pdf
git push -u origin feature/invoice-pdf
# open PR → review → green CI → merge → deploy

#Difference with Trunk-Based

They are close relatives. GitHub Flow formalizes the Pull Request as the entry gate and tolerates somewhat longer branches; Trunk-Based pushes for branches of hours and even more frequent integration. If your PRs take days to merge, you are effectively doing neither.

When NOT to use it

Software with several versions in production at once.
When you need a staging branch with formal per-environment approvals (see GitLab Flow).

Tradeoffs

Pro	Con
Very easy to explain and adopt	No native concept of versions/releases
Review built in via PR	A long branch degrades it into an "eternal feature branch"
Natural continuous deployment	Depends on CI and an always-green `main`

#git #branching #github #pull-request