By admin , 29 April 2026

The simplest workflow that works

GitHub Flow is a pragmatic, lightweight model: main is always deployable; everything else is a short-lived branch behind a pull request. It is what the GitHub team itself uses and what most open-source projects converge on.

The six steps

  1. Create a branch off main.
  2. Add commits.
  3. Open a pull request.
  4. Discuss and review.
  5. Deploy (optional - some teams deploy from PRs to staging).
  6. Merge to main.

A worked example

git checkout main
git pull
git checkout -b feature/avatar-upload
# ...work, commit...
git push -u origin feature/avatar-upload
gh pr create --fill

After review:

gh pr merge --squash --delete-branch
git checkout main
git pull

Three merge strategies

  • Merge commit - preserves branch history, adds a merge commit on main.
  • Squash and merge - flattens the branch into one commit on main. Most common.
  • Rebase and merge - replays each branch commit individually, no merge commit.

Branch protection

GitHub Flow assumes main is protected:

  • Require PR before merge.
  • Require status checks (CI, lint, tests).
  • Require at least one approving review.
  • Disallow direct pushes.
  • Optionally require linear history.

Why GitHub Flow works

  • One long-lived branch - easy mental model.
  • PRs are the unit of review and discussion.
  • Tooling (GitHub, GitLab, Bitbucket) is built around exactly this model.
  • Continuous deployment is straightforward.

What it does not provide

  • No mechanism for parallel supported versions - use release branches separately.
  • No staging branch - use environments or feature flags.
  • No prescribed branch names - your team decides.

Daily workflow

# Start fresh
git checkout main && git pull
git checkout -b fix/login-redirect

# Work, commit, push
git push -u origin fix/login-redirect

# Open PR
gh pr create --title "Fix login redirect" --body "Fixes #123"

# After approval and CI green
gh pr merge --squash --delete-branch

# Sync local
git checkout main && git pull
git branch -d fix/login-redirect

Best practices on top

  • Keep PRs under 400 lines of diff.
  • One concern per PR - reviewers love it.
  • Open PRs early as drafts to surface design discussions.
  • Self-review before requesting review.

When to graduate

If you find yourself maintaining multiple released versions concurrently, or running long QA cycles, GitHub Flow alone may not be enough. Add release branches, but resist adding a develop branch - that way lies Git Flow's complexity. For 90% of web teams, GitHub Flow plus branch protection plus CI is the entire process.