GitHub Flow is a lightweight, branch-based Git workflow described by Scott Chacon in 2011, in which main is always deployable. Every change gets a short-lived branch from main, and a Pull Request serves for review, discussion and CI validation before the merge. In Chacon's original formulation each merge is deployed immediately, while GitHub's current official description has no deployment step after the merge.

GitHub Flow

Details

Core Concepts:

  • A lightweight, branch-based workflow where main is always deployable

  • Feature branches are short-lived, created from main for every change

  • Pull Requests are the central collaboration mechanism — used for code review, discussion, and CI validation before merging

  • Merging to main triggers immediate deployment (continuous delivery)

  • Branch naming reflects the work: issue number or short descriptive slug

    Workflow steps

    1. Create a branch from main (named after the issue or feature)

    2. Commit changes with descriptive messages

    3. Open a Pull Request early for visibility and feedback

    4. Discuss, review, and iterate until the PR is approved

    5. Merge to main — main is always in a deployable state

    6. Deploy immediately after merge

    Key Proponent

    Scott Chacon ("GitHub Flow", 2011)

When to Use:

  • Teams practicing continuous delivery or continuous deployment

  • Projects where main must always be production-ready

  • Issue-driven or ticket-driven development workflows

  • Agentic coding workflows where context brevity matters

Current Status:

  • The prior most plausibly reproduces Scott Chacon’s original 2011 formulation, where continuous deployment is the point — "anything in the master branch is deployable", and merged work is deployed immediately, often several times a day

  • GitHub’s current official description has narrowed to a generic branch → PR → review → merge workflow with no deployment step at all — say which of the two you mean