← Back to Git Course | Chapter 3: Branching | Lesson 9 of 9

GitHub Flow

GitHub Flow is a simple house rule: keep one main version, make a small side copy for each new idea, and merge it back after friends check it.

In this page:

  1. What is GitHub Flow
  2. Branch From Main
  3. Open a Pull Request Early
  4. Merge and Deploy
  5. GitHub Flow vs GitFlow
Syntax
bash 
git switch -c branch-name
git add file_name
git commit -m "message"
git push -u origin branch-name
# then open a pull request and merge into main

What is GitHub Flow

GitHub Flow is a lightweight branching model built around a single long-lived main branch and short-lived feature branches -- unlike GitFlow's multiple permanent branches (develop, release, hotfix), GitHub Flow deliberately keeps only one permanent branch to minimize process overhead for teams that deploy continuously.

Example: What is GitHub Flow

bash 
git checkout main
git checkout -b add-search

Branch From Main

Every piece of work -- a feature, a fix, an experiment -- gets its own descriptively-named branch cut directly from main, with no intermediate develop branch to merge through first.

Example: Branch From Main

bash 
git checkout main
git checkout -b fix-header-bug

Open a Pull Request Early

GitHub Flow encourages opening a pull request as soon as a branch exists, even before the work is complete -- the PR becomes a running conversation thread for feedback, CI results, and progress visibility, not just a final review gate.

Example: Open a Pull Request Early

bash 
git push -u origin fix-header-bug
# open a pull request immediately, even before work is complete

Merge and Deploy

Once a pull request is reviewed and its checks pass, it's merged directly into main -- and because main is meant to always be deployable in this model, that merge is typically followed immediately by an automatic or one-click deployment to production.

Example: Merge and Deploy

bash 
git checkout main
git merge fix-header-bug
git push origin main

GitHub Flow vs GitFlow

GitHub Flow trades GitFlow's structured release/hotfix branches for simplicity: there's no separate develop branch to keep in sync, and no scheduled release branch -- every merge to main is a potential deploy, which suits teams practicing continuous delivery far better than GitFlow's more deliberate, versioned release cadence.

Example: GitHub Flow vs GitFlow

bash 
git checkout -b feature-x main
# merges straight to main, no develop branch
Related Topics

GitHub Edit Code · GitHub Remote Branch · Git GitHub Introduction · Git GitHub Actions Introduction

{# common_mistakes/chapter_summary/browser_support: on Hindi pages the view already swaps in the hi_ translation fields (or blanks these out if untranslated), so this renders correctly for both languages without a lang_code check here. #}
Common Mistakes
  1. Committing directly to main instead of creating a branch first, which bypasses review.
  2. Naming branches vaguely like fix or test, when descriptive names such as add-search show the purpose.
  3. Leaving a branch open for weeks, so main moves on and the merge becomes hard; keep branches short-lived.
Chapter Summary
  • Branches let you work on separate lines of development, and you create and change them with git branch, git checkout, and git switch.
  • git merge, git rebase, and git cherry-pick bring changes together.
  • Branch strategies and GitHub Flow describe how teams organize branches.
🔒

Chapter Quiz — Complete all 9 topics to unlock

0/9 topics done

Complete these topics first:

← Previous Lesson Git Branch Strategies Next Lesson → Git Remote Introduction

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.