Cheatsheet: Team workflows: GitHub Flow, GitFlow, Trunk-based, Forking

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.

The four workflows side by side

Dimension	GitHub Flow	GitFlow	Trunk-based	Forking
Long-lived branches	1 (main)	2 (main + develop)	1 (trunk)	1 per repo (main) across N repos
Repositories	1 (shared)	1 (shared)	1 (shared)	1 canonical + N forks
Branch lifetime	Hours to days	Days to weeks	Hours, ideally	Per-fork; PRs days to weeks
Release model	Continuous, on every merge	Formal release branches + tags	Continuous, behind flags	Maintainer-gated; tag-based
Ceremony	Low	High	Medium	Medium (fork sync + PR review)
Best fit team size	2-50	10-100	10-1000+	Any (with external contributors)
Best fit product type	Web app, SaaS	Versioned desktop/mobile, regulated	High-velocity SaaS, monorepo	Open-source, multi-stakeholder, restricted-write
CI requirement	Strong	Medium	Very strong	Strong (must catch contributor mistakes)
Feature flag requirement	Optional	Optional	Required	Optional
External contributor support	Limited	Limited	Limited	Designed for it

Compositional note: Forking sits ON TOP of one of the first three. Most open-source maintainers run GitHub Flow internally + Forking externally. Don’t pick “GitHub Flow vs Forking”; pick “what does my team do internally” + “do we accept external forks too.”

Branch protection rules, typical setup

For GitHub Flow’s main:

[x] Require pull request before merging
[x] Require approvals (1 for small teams, 2+ for security-sensitive)
[x] Require status checks to pass (CI green)
[x] Require branches to be up to date before merging
[ ] Require linear history (optional)
[x] Restrict who can push directly (only via PR)
[x] No force-pushes
[x] No deletions

For GitFlow’s main AND develop: same as above on both. Add similar rules to active release/* and hotfix/* branches.

For Trunk-based’s trunk:

[x] Require status checks to pass (CI green), most important
[x] Require approvals on PRs (for non-trivial changes)
[ ] Require pull request before merging (optional; some teams allow trusted direct commits)
[x] No force-pushes
[x] No deletions

CI gate stack (recommended starter)

1. Linting (per-file checks)
2. Type checking (per-file)
3. Unit tests (per-function)
4. Integration tests (cross-module)
5. Build verification (the artifact compiles)
6. Security scans (static analysis)
7. E2E tests (most critical journeys only; optional but recommended)
8. Performance benchmarks (for perf-sensitive code; optional)

The discipline: each gate has a cost (developer wait time) and a benefit (caught bugs). Pick gates whose benefit > cost.

The decision rule

Start with GitHub Flow if:
  - 2-50 engineers
  - Web app or SaaS
  - Single production environment
  - Decent CI

Choose GitFlow only if:
  - Multiple supported versions (e.g., v8 + v9 + v10)
  - Formal release cycles (mobile, embedded, regulated)
  - Release-branch QA gates

Migrate to Trunk-based when:
  - 100+ engineers AND
  - Mature CI (fast + comprehensive) AND
  - Feature flag infrastructure

Add Forking on top of the above when:
  - Publishing an open-source project
  - Accepting contributions from people without write access
  - External contractors / partners with limited write
  - Wanting to scale to many contributors without giving all push access

Use a hybrid almost always.
The pure workflows are reference points; deviations are normal.

The decision flowchart

                          START
                            │
                            ▼
             ┌──────────────────────────────┐
             │ Do you ship multiple         │
             │ supported versions           │
             │ simultaneously?              │
             │ (e.g., v8 + v9 + v10)        │
             └──────────────────────────────┘
                    │              │
                  YES             NO
                    │              │
                    ▼              ▼
              ┌─────────┐    ┌──────────────────────────┐
              │ GITFLOW │    │ Do you have:             │
              └─────────┘    │   - 100+ engineers AND   │
                             │   - Mature CI AND        │
                             │   - Feature flags?       │
                             └──────────────────────────┘
                                   │            │
                                 YES           NO
                                   │            │
                                   ▼            ▼
                             ┌─────────────┐  ┌─────────────────┐
                             │ TRUNK-BASED │  │ GITHUB FLOW     │
                             └─────────────┘  │ (default)       │
                                              └─────────────────┘

       At any branch above, ALSO ask:
       ┌──────────────────────────────────────────────┐
       │ Do you accept contributions from outside     │
       │ your team (open source, external partners,   │
       │ contractors without full write access)?      │
       └──────────────────────────────────────────────┘
              │                       │
            YES                      NO
              │                       │
              ▼                       ▼
       ┌──────────────────────┐   ┌──────────────────┐
       │ ALSO add FORKING     │   │ No Forking       │
       │ (compose with your   │   │ needed; team     │
       │ chosen internal      │   │ shares one repo  │
       │ workflow above)      │   │ directly.        │
       └──────────────────────┘   └──────────────────┘

Reading the flowchart: the top half picks your INTERNAL team workflow (one of three). The bottom half asks separately whether you accept EXTERNAL contributions. Forking is additive, not a fourth alternative to the first three. Most Clawdemy students who publish open-source work end up at “GitHub Flow internally + Forking externally.”

Common hybrids

Hybrid	Description	When to use
GitHub Flow + tags	Pure GHF day-to-day; tag specific main commits as releases	Need versioned releases but not GitFlow’s overhead (80% of “versioning needs”)
Trunk-based + PR	Always PR but PRs live hours; trunk always deployable	Want trunk-based velocity + code review safety
GitFlow lite	Drop develop; use release/* + hotfix/* off main as needed	Need release branches sometimes but not daily integration

Workflow recognition drill, model identifications (Drill 1)

1. SaaS, 15 engineers, continuous deploy, 5min CI yields GitHub Flow. Standard fit. Probably with branch protection on main.
2. Mobile, v8 + v9 + v10 supported, App Store reviews yields GitFlow. The multi-version-supported requirement is exactly what GitFlow solves.
3. 400 engineers, monorepo, feature flags, fast CI yields Trunk-based. The scale + infrastructure match.
4. Open-source, fork-based contributions, tagged releases yields GitHub Flow + release tags hybrid. Maintainers merge PRs to main; specific commits get tagged for releases.
5. Healthcare-regulated, formal QA sign-off, gated releases yields GitFlow. The regulated-release-gate requirement maps to GitFlow’s release branches.

Workflow pick drill, model answers (Drill 2)

1. Personal side project, Vercel yields No formal workflow. Just commit to main. No team, no review needed, no production users at risk.
2. Two-person startup, B2B SaaS yields GitHub Flow. Protect main with PR + 1 approval + CI green.
3. 10-person, desktop app yields GitFlow if shipping multiple supported versions; GitHub Flow + release tags if single-version. Most startups start with the latter and migrate only if needed.
4. 30-person, SaaS, no feature flags yields GitHub Flow. Trunk-based requires feature flag infrastructure that doesn’t exist yet.
5. 30-person, SaaS, has feature flags yields GitHub Flow or Trunk-based-with-PR hybrid. Could go either way. Many teams default to GitHub Flow until the engineering count makes Trunk-based necessary.
6. 200-person, monorepo, mature CI yields Trunk-based. The scale + infrastructure match. Strong code review culture is the remaining requirement to verify.

Branch protection setup drill, model rules (Drill 3)

GitHub Flow main:

• Require PR before merging
• Require 1+ approvals (CODEOWNER-aware)
• Require CI green
• Require branch up-to-date before merge
• No force-push
• No deletions

GitFlow main + develop:

• Same as above on both
• For active release/* branches: require PR + approval + CI green; allow merges from feature branches; deletion allowed when release is over
• For active hotfix/* branches: similar; deletion allowed when hotfix is merged

Trunk-based trunk:

• Require CI green (the most important rule)
• Require PR for non-trivial changes (some teams require for all changes; others allow direct commits for trusted committers)
• No force-push
• No deletions

The trunk-based pattern is interesting: the rule set is LESS strict than GitHub Flow on the PR requirement but MORE strict on CI. The trade-off matches the workflow’s philosophy: trust the committer for small things; trust the tests for everything.

What’s in L10

L10 introduces releases and tags, the formal “this commit is the v2.0 release” mechanism that all four workflows interact with. You’ll learn git tag (annotated vs lightweight), semantic versioning (semver), release notes generation, and how releases differ across the four workflows. After L10, you can mark and announce a release for any project.