2.2. The GitHub Flow

Ask a team "what's your Git workflow?" and if they use GitHub, the answer is usually some version of the same lightweight loop — and the exam expects you to recognize its shape.

💡 First Principle: The GitHub Flow is a branch-per-change workflow built around one rule: main is always deployable. Anything new — a feature, a fix, an experiment — happens on its own branch, gets proposed as a pull request, gets reviewed, and only merges into main once it's ready. Because main never holds half-finished work, a team can deploy from it at any time without first checking whether it's "safe."

This loop repeats constantly and in parallel — many branches, many pull requests, all converging back on the same protected main branch. It's what makes GitHub Flow different from heavier branching models: there's exactly one long-lived branch to reason about.

⚠️ Exam Trap: GitHub Flow does not use permanent develop or release branches the way Git Flow does. There's one long-lived branch (main); everything else is short-lived and deleted after merging.

Reflection Question: Why does keeping main "always deployable" reduce risk compared to a workflow where several people commit directly to it?