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

What this lesson covers

L9 introduces the four production team workflows that dominate the industry. The mechanics from Phase 2 (branches, PRs, conflicts, remotes) become the building blocks; workflows are the patterns that orchestrate those building blocks at team scale.

Five load-bearing ideas:

GitHub Flow is the simple default. One main branch + ephemeral feature branches + PR + merge + deploy. Used by 80% of modern web teams. Start here unless you have a clear reason not to.
GitFlow is the heavy versioned-release pattern. Two long-lived branches (main + develop) + formal release branches + hotfix branches. Only use it if you ship multiple supported versions.
Trunk-based Development is the high-velocity pattern. One trunk + extremely short-lived branches + feature flags + heavy CI. Used by FAANG-scale orgs and high-velocity SaaS teams.
Forking is the open-source pattern. One canonical repo + N forks (one per contributor). Composes WITH one of the first three (the maintainer’s team uses GitHub Flow internally + accepts forked PRs externally). The default for every public open-source project.
Branch protection rules + CI gates are how you enforce the workflow. Without them, “follow the workflow” is just a wish. Tooling enforces convention.

By the end of L9, the reader will be able to

Describe each of the four workflows in their own words
Identify which fits a given team context
Apply branch protection rules and CI gates appropriately
Recognize hybrid workflows in the wild and reason about what they borrow
Use the decision rule to pick a workflow for a new project
Articulate workflow migration triggers (when teams switch)
Set up a public open-source project using the Forking workflow so external contributors can submit changes

Prerequisites

L1-L8 (everything in Phases 1 + 2)
An understanding of CI/CD concepts (not deep, but you should know what “continuous deployment” means)
Familiarity with at least one feature-flag concept (LaunchDarkly, env-vars, simple booleans)

Reading map

L9 is content-dense by design. Read in three passes:

Pass 1, The three workflows: GitHub Flow + GitFlow + Trunk-based, one section each. After this, you can name the three and explain each at high level.

Pass 2, The enforcement + comparison: Branch protection rules + CI gates + hybrid workflows + the decision rule. After this, you can pick and enforce a workflow.

Pass 3, Scenarios + migrations + multi-agent: Six team-scale scenarios + when teams migrate + Phase 4 foreshadowing. After this, you have the full mental model for how workflows shape engineering culture.

New developers should walk through all three passes. The decision rule is the most operationally useful part.

Experienced developers should focus on the hybrid workflows section and the migration triggers. These map directly onto real-world engineering decisions.

Managers and TPMs should read the dedicated framing section. Workflow choice is a leadership decision, not an engineering preference.

What this lesson deliberately does not cover

Release tag mechanics (deferred to L10)
Rebase deep-dive (deferred to L12)
Cherry-pick across release branches (deferred to L11)
CODEOWNERS file specifics (covered in passing; GitHub docs are authoritative)
Specific feature-flag implementations (LaunchDarkly, Unleash, env-var flags, beyond T7 scope)
Branch protection rule syntax for GitLab and Bitbucket (similar to GitHub; platform docs authoritative)

If you want release mechanics, L10 is next. If you want rebase, L12 covers it.

Estimated reading + practice time

40-50 minutes for reading (longer because of the three-workflows-with-detailed-tradeoffs format). 30-40 minutes for the practice exercises (includes a “pick a workflow for this scenario” drill).

Total: ~70-90 minutes including practice. L9 is the second-longest lesson in T7 because the workflow choice is foundational for Phase 3 + Phase 4.