Use Cases

  • Teams practicing continuous deployment (deploy on every merge to main)
  • SaaS applications with frequent, unconstrained releases
  • Projects with automated testing and deployment pipelines
  • Teams where every engineer is responsible for what they ship

Components

  • main (main-branch): Always deployable code, representing production state
  • feature branches (supporting-branch): Branches for new features, branched from main
  • pull requests (policy): All changes must go through pull requests for review

Steps

  1. Step 1: Create feature branch: Create a branch from main for your work
  2. Step 2: Develop and commit: Make commits to your feature branch
  3. Step 3: Open pull request: Open a pull request to propose merging your changes
  4. Step 4: Code review: Team reviews the code, provides feedback, and ensures tests pass
  5. Step 5: Merge to main: After approval, merge to main. Choose a merge strategy deliberately— squash merge gives a clean linear history but loses individual commit granularity; rebase merge preserves commits linearly; merge commit preserves full branch topology.
  6. Step 6: Deploy: Main is automatically deployed to production after merge

Workflow Diagram

gitGraph commit id: "deployed" branch feature checkout feature commit id: "work" commit id: "more work" checkout main merge feature tag: "deploy"
Step 1 of —

Common Gotchas

  • No staging environment: Changes go directly from feature to production, which can be risky without comprehensive automated testing important
  • Difficult to coordinate releases: If you need to bundle multiple features into a single release, GitHub Flow makes this challenging important
  • Hotfixes require special handling: There's no dedicated hotfix workflow — urgent fixes go through the same pull request process, which is usually fast enough given CI automation, but adds friction compared to Gitflow's hotfix branches mild
  • Merge strategy trade-offs are real: Squash merge keeps history clean but makes git bisect harder on multi-commit features. Rebase merge preserves commits but rewrites hashes. Merge commit preserves context but creates a non-linear graph. No universal right answer. mild
  • Requires strong CI/CD: Without reliable automated testing and deployment, direct-to-production merges are dangerous critical

Best Practices

  • Enable branch protection on main with required reviews and CI checks
  • Require at least one code review approval before merge
  • Require all CI checks to pass before merge — treat a broken main as a P0 incident
  • Choose a merge strategy deliberately (squash, rebase, or merge commit) and enforce it consistently
  • Deploy automatically from main to production — remove manual deploy steps to reduce risk
  • Keep feature branches short — a branch open for more than a few days starts accumulating drift

Pros and Cons

Pros

  • Simple and easy to understand — one rule: main is always deployable
  • Optimized for continuous deployment with minimal process overhead
  • Encourages small, frequent changes that are easier to review and revert
  • Excellent CI/CD integration — natural trigger point on every merge
  • Fast path to production for web and SaaS applications

Cons

  • No staging or pre-production branch — production is the first real environment
  • Difficult to coordinate feature releases across multiple dependent branches
  • Requires strong automation infrastructure — without it, direct-to-production merges are dangerous
  • Less suitable for mobile apps where app store approval delays decouple the merge from the release
  • No built-in version tagging strategy — externally managed or commit SHA-based

Real-World Examples

  • GitHub: GitHub itself uses GitHub Flow to deploy github.com. Scott Chacon documented that GitHub deploys to production dozens of times per day, sometimes multiple times per hour. Engineers ship and are responsible for what they merge.
  • Shopify: Shopify's engineering team uses a GitHub Flow variant. Feature flags handle large changes, and main is always in a state that can be safely deployed. Their CI pipeline gates every merge, and deploys are automated.
  • Heroku: Heroku's platform team popularized the continuous delivery model that GitHub Flow embodies. Review Apps (ephemeral environments per PR) extend the model by giving each pull request its own testable environment.