1.4GitHub Flow in Detail

GitHub Flow, popularized by GitHub itself, uses a single main branch. All work happens on feature branches that merge via pull requests. There are no develop or release branches.

main ──────*──*──*──*──*──*──*──*──*──── (always deployable)
           ^  ^  ^  ^  ^  ^  ^  ^  ^
           PRs from feature branches

How GitHub Flow Works

1. main is always deployable. If something is on main, it is production-ready.
2. Feature branches branch from main, contain all work, and merge back via pull request.
3. Pull requests are the primary quality gate. CI runs all tests on the PR before merge.
4. Deploy from main after merge. Many teams deploy automatically on every merge.

Implications for Testing

• Test on PR: Every pull request triggers the full test suite. This is your primary quality gate.
• Main is always deployable: If tests pass on the PR and the PR is merged, main should be safe to deploy at any time.
• No stabilization phase: There is no release branch. If something is broken on main, fix it with another PR.
• Simpler environment mapping: Feature branches deploy to preview environments, main deploys to production.

When to Use GitHub Flow

• Your team does continuous deployment (deploy multiple times per day).
• You have a single version in production (typical for SaaS).
• Your CI pipeline is fast and reliable enough to gate PRs effectively.
• Your team is small to medium and does not need the structure of GitFlow.

Common Mistake: Treating main as a "development branch" where broken code is acceptable. In GitHub Flow, main must always be deployable. If your tests do not run on every PR, GitHub Flow will burn you.