Summary: Team workflows: GitHub Flow, GitFlow, Trunk-based, Forking
Four workflows, one decision
Section titled “Four workflows, one decision”| Workflow | Long-lived branches | Ceremony | Best fit |
|---|---|---|---|
| GitHub Flow | 1 (main) | Low | Web apps, SaaS, 2-50 engineers, single production |
| GitFlow | 2 (main + develop) | High | Versioned products (mobile, desktop, embedded, regulated) |
| Trunk-based | 1 (trunk) | Medium | High-velocity SaaS, 100+ engineers, mature CI + feature flags |
| Forking | 1 (per repo, across N repos) | Medium | Open-source, external contributors, restricted-write internal |
The decision rule
Section titled “The decision rule”- Default to GitHub Flow unless you have a clear reason not to.
- Choose GitFlow only if you ship multiple supported versions.
- Migrate to Trunk-based when you have 100+ engineers + mature CI + feature flag infrastructure.
- Add Forking on top when you publish an open-source project or accept contributions from people without write access.
- Use hybrids almost always: pure workflows are reference points; your team’s needs drive deviations.
Forking is not exclusive with the other three. A solo open-source maintainer typically runs GitHub Flow internally AND uses Forking externally. The first three describe your team’s INTERNAL workflow; Forking describes how OUTSIDERS contribute.
Branch protection rules (the enforcement layer)
Section titled “Branch protection rules (the enforcement layer)”For long-lived branches:
- Require PR before merging
- Require approvals (1 for small teams; 2+ for security-sensitive)
- Require CI green
- Require branch up-to-date before merge
- No force-push
- No deletions
- Optionally: require linear history
CI gates (the quality layer)
Section titled “CI gates (the quality layer)”Typical gates: linting, type checking, unit tests, integration tests, build verification, security scans, optional E2E + performance.
The discipline: every gate has a cost (wait time) and a benefit (caught bugs). Pick gates whose benefit > cost.
Trunk-based requires three things
Section titled “Trunk-based requires three things”- Heavy CI: must catch breaks fast
- Feature flag infrastructure: to hide incomplete work
- Strong code review culture: many direct commits without PR
Without all three, trunk-based breaks the team.
Hybrid examples
Section titled “Hybrid examples”- GitHub Flow + release tags: day-to-day GitHub Flow; releases tagged on main (covers 80% of versioned-release needs)
- Trunk-based + light PR: every change goes through PR but PRs live hours, not days
- GitFlow lite: drop the develop branch; use
release/*andhotfix/*only when needed
Phase 3 opened
Section titled “Phase 3 opened”You now understand the workflow taxonomy. L10 covers release mechanics (tags, semver, release notes). L11 covers cherry-pick + stash. L12 covers rebase deeper.
Voice anchor
Section titled “Voice anchor”Git stores snapshots. Every other command is just navigating those snapshots.
A workflow is a convention about which branches exist and how they relate to the production snapshot.