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