Chapter 28: Git GitHub Flow
GitHub Flow
This is not just another Git command — it’s a complete lightweight workflow (a way of working) that GitHub itself invented and still promotes in 2026 as the default recommendation for most teams.
Many companies (especially web, SaaS, startup, open-source, mobile-app teams that deploy frequently) use GitHub Flow because it is:
- extremely simple
- fast
- safe for continuous delivery
- perfect for Pull-Request-based reviews
- works beautifully with GitHub Actions / Vercel / Netlify auto-deploys
I’m going to explain it like I’m sitting next to you walking through a real project on your laptop + GitHub tab open — step by step, with real commands, real commit messages, what GitHub screens look like, and why each step exists.
What is GitHub Flow? (super clear mental model)
GitHub Flow has one golden rule:
Everything happens through Pull Requests to the main branch.
There is only one long-lived branch: main (used to be called master — now almost universally main since 2020–2023)
All other branches are short-lived (usually 1 hour to 4 days) and exist only to propose changes via a Pull Request.
Picture it like this:
- main = the official, deployed-to-production, always-working version
- Every new feature / bugfix / refactor = a temporary branch
- You never commit directly to main
- You always create a Pull Request → get review → merge → delete branch
After merge → main is automatically deployed (or very soon after)
That’s the entire philosophy.
GitHub Flow – Step-by-Step Realistic Example (copy-paste ready)
Project: small todo web app
Step 1 – Start the day fresh (always)
|
0 1 2 3 4 5 6 7 8 |
cd todo-app git switch main git pull origin main |
→ Your local main is now identical to GitHub’s main (production)
Step 2 – New task arrives “Add dark mode toggle button”
Create a descriptive branch (2026 naming convention):
|
0 1 2 3 4 5 6 |
git switch -c feat/dark-mode-toggle-button |
Naming pattern most teams use:
- feat/… – new feature
- fix/… – bug fix
- refactor/… – no behavior change
- docs/… – documentation
- chore/… – build/tooling
- Ticket ID if you use Jira/Linear: feat/DEV-123-dark-mode
Step 3 – Do the work (small, frequent commits)
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
# edit files... git add . git commit -m "feat(ui): add dark mode CSS variables and toggle button" # more work... git commit -m "feat: persist dark mode choice in localStorage" # small fix git commit -m "fix: correct dark mode class on body instead of html" |
Step 4 – Push the branch to GitHub
First time:
|
0 1 2 3 4 5 6 |
git push -u origin feat/dark-mode-toggle-button |
Later pushes:
|
0 1 2 3 4 5 6 |
git push |
Now go to github.com → your repo
You will see a yellow banner:
“feat/dark-mode-toggle-button had recent pushes less than a minute ago”
→ Click green button Compare & pull request
Step 5 – Create the Pull Request (very important screen)
GitHub opens the “Open a pull request” page:
- Base: main ← compare
- Compare: feat/dark-mode-toggle-button
Fill it properly (2026 best practice):
Title (should match squash commit style):
|
0 1 2 3 4 5 6 |
feat: add dark mode toggle with system preference & localStorage |
Description:
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
## What - Added CSS variables for light/dark themes - Toggle button in header - Saves preference in localStorage - Detects system dark mode on first load ## Why Improves accessibility & user experience in low-light environments ## How to test 1. Open the app 2. Click moon/sun icon 3. Refresh → preference remembered 4. Change OS theme → app follows on first load Closes DEV-456 |
Add reviewers, assignees, labels, link to ticket.
Click Create pull request
Step 6 – Review & merge (team or solo)
- Teammate (or you) reviews code on GitHub
- Comments inline
- Requests changes
- Approves
When ready → two popular merge options in 2026:
- Squash and merge (most common for clean history) → All your 3–5 small commits become one clean commit on main
- Rebase and merge → keeps your commits but linear on top of main
Click green Squash and merge → confirm
→ GitHub auto-deletes the branch (option checked by default)
Step 7 – Update your local machine
Back in terminal:
|
0 1 2 3 4 5 6 7 8 9 |
git switch main git pull origin main git fetch --prune # removes deleted remote branches from your list git branch -d feat/dark-mode-toggle-button # delete local branch |
Done! Your dark mode feature is now in production (or next deploy).
GitHub Flow vs Other Workflows – Quick 2026 Comparison
| Workflow | Long-lived branches | Deployment frequency | Review required? | Complexity | Most used in… |
|---|---|---|---|---|---|
| GitHub Flow | Only main | Daily / multiple per day | Yes (PR) | Very low | Web, SaaS, startups, OSS, mobile |
| Git Flow | main + develop + release + hotfix | Weekly–monthly | Yes | High | Enterprise, desktop, versioned releases |
| Trunk-Based | Almost none | Many per day | Optional/small PRs | Medium | Big tech, monorepos, high velocity |
Your Daily GitHub Flow Cheat Sheet (2026 style)
|
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
# Morning git switch main && git pull # New task git switch -c feat/DEV-123-dark-mode # Work → commit often git commit -m "feat: add dark mode toggle" # Ready for review git push -u origin feat/DEV-123-dark-mode # → create PR on GitHub # → wait for review / fix comments # → squash & merge on GitHub # After merge git switch main && git pull git branch -d feat/DEV-123-dark-mode |
Got the full picture now? GitHub Flow = short-lived branches + Pull Requests + merge to main + auto-deploy
Next?
- Want to do a full live simulation with a dummy repo + PR?
- How to write great PR descriptions?
- Or what happens when two people work on same branch (merge conflict in PR)?
Just tell me — we’ll keep building together. You’re doing fantastic! 🚀
