Chapter 14: Git Workflow

Git Workflow ☕

Up to now we’ve learned individual pieces: commits, branches, merge, stash, tags, history… Git Workflow is how you put all those pieces together into a repeatable, team-friendly daily/weekly process so that:

• Code stays stable
• Features ship fast (or on schedule)
• Conflicts are minimized
• Everyone knows what to do next
• History is readable years later
• Deployments don’t break production

There is no single “best” Git workflow — it depends on:

• Team size (solo vs 50 people)
• Release frequency (daily deploys vs quarterly versions)
• Project type (web app, mobile app, library, embedded software)
• Whether you need to support multiple versions in production

In 2026 the three most talked-about and used workflows (by far) are:

1. GitHub Flow (most popular for web/apps with continuous deployment)
2. Trunk-Based Development (very popular in big/fast-moving companies)
3. GitFlow (still used, especially in enterprise/legacy/desktop software with scheduled releases)

We’ll explain each one like we’re actually using it on a small todo-app project — with real commands and why/when to choose it.

1. GitHub Flow – The Modern Default (Simplest & Most Popular in 2026)

Who uses it? GitHub itself, most open-source projects, startups, web/API teams doing daily/weekly deploys, small-to-medium teams.

Core idea: One long-lived branch (main), short-lived feature/bugfix branches, Pull Requests for review, merge to main → deploy immediately (or very soon).

Daily flow (real example)

1. Start day fresh

   Bash

   PHP

   0 1 2 3 4 5 6 7

   git switch main git pull origin main

2. New task: “Add dark mode toggle”

   Bash

   PHP

   0 1 2 3 4 5 6

   git switch -c feature/dark-mode-toggle

3. Work (many commits – small & logical!)

   Bash

   PHP

   0 1 2 3 4 5 6 7 8 9 10 11

   # edit files... git add . git commit -m "Add dark mode CSS variables" # more work... git commit -m "Implement toggle button + localStorage save" git commit -m "Add system preference detection"

4. Ready? Push & create Pull Request

   Bash

   PHP

   0 1 2 3 4 5 6

   git push -u origin feature/dark-mode-toggle

   → Go to GitHub → “Compare & pull request” → write description → assign reviewers → link to ticket

5. Review happens on GitHub (comments, suggestions, approvals)

6. After approval → squash/merge (or rebase/merge) to main

   → GitHub button: “Squash and merge” (clean history)

7. Delete branch (auto or manual)

   Bash

   PHP

   0 1 2 3 4 5 6 7 8

   git switch main git pull git branch -d feature/dark-mode-toggle

Pros in 2026

• Very simple (only one long branch)
• Fast feedback loop (PRs = early review)
• Linear-ish history if you squash
• Perfect for CI/CD (every merge → auto-deploy)

Cons

• Can have big PRs if not broken small
• Less support for hotfixes on old versions

When to use → Web/apps, continuous delivery, teams < 20–30 people, you deploy often.

2. Trunk-Based Development – The High-Speed / Big-Tech Favorite

Who uses it? Google, Meta, many FAANG-level teams, teams with strong CI/CD + feature flags.

Core idea: Everyone commits very frequently (multiple times/day) directly to main/trunk (or very short-lived branches < 1–2 days). Use feature flags/toggles to hide unfinished work.

Daily flow example

1. Start day

   Bash

   PHP

   0 1 2 3 4 5 6 7

   git switch main git pull --rebase origin main   # keep linear

2. Small change or behind flag

   Bash

   PHP

   0 1 2 3 4 5 6 7 8 9 10

   git switch -c temp/dark-mode   # branch < few hours # code... git commit -m "Add dark mode behind NEW_DARK_MODE flag" git push # create small PR or direct push if trusted

3. Merge fast (small PRs or direct push if solo/small team)

4. Deploy → flag off for users → later turn on gradually

Key techniques

• Very small commits/PRs (< 200–400 LOC ideal)
• Feature flags (LaunchDarkly, ConfigCat, home-made if-statements)
• Automated tests on every commit/PR
• No long-lived branches

Pros

• Extremely fast integration (no merge hell)
• Always releasable main
• Encourages small, safe changes

Cons

• Requires strong automated testing + flags
• Can feel scary for juniors
• History noisier without squash

When to use → Large/fast teams, monorepos, you want to ship many times per day.

3. GitFlow – The Classic / Structured One (Still Alive in 2026)

Who uses it? Enterprise, desktop/mobile apps with versioned releases, teams with strict QA/release cycles, companies maintaining multiple versions (v1.2 still in support while v2.0 out).

Core branches

• main → production-ready tags (v1.0.0, v1.0.1…)
• develop → integration branch (next release)
• feature/* → short-lived
• release/* → prepare version (bug fixes, version bump)
• hotfix/* → urgent production fixes

Flow example

1. Start new feature from develop

   Bash

   PHP

   0 1 2 3 4 5 6 7 8

   git switch develop git pull git switch -c feature/user-auth

2. Finish → merge to develop

   Bash

   PHP

   0 1 2 3 4 5 6 7 8

   git switch develop git merge --no-ff feature/user-auth git push

3. Ready for release? Create release branch

   Bash

   PHP

   0 1 2 3 4 5 6 7 8

   git switch -c release/1.3.0 develop # bump version, fix last bugs, update changelog git commit -m "Prepare release 1.3.0"

4. Test/QA on release branch

5. Done? Merge to both main & develop + tag

   Bash

   PHP

   0 1 2 3 4 5 6 7 8 9 10 11 12 13

   git switch main git merge --no-ff release/1.3.0 git tag -a v1.3.0 -m "Version 1.3.0 released" git push origin main --tags   git switch develop git merge --no-ff release/1.3.0 git push

6. Urgent bug in prod? Hotfix from main

   Bash

   PHP

   0 1 2 3 4 5 6 7 8 9

   git switch -c hotfix/security-patch main # fix git commit -m "Fix XSS in login" # merge to main + develop + tag v1.3.1

Pros

• Clear separation production/next/dev
• Supports multiple versions/hotfixes
• Structured for large teams/QA gates

Cons

• Many long-lived branches → merge hell
• Slower release cycle
• Overkill for web/continuous deploy

When to use → Scheduled releases (quarterly), need to patch old versions, regulated industries.

Quick Comparison Table (2026 Perspective)

Your First Workflow Recommendation (as beginner in Hyderabad 2026)

Start with GitHub Flow — it’s the easiest to learn, matches most tutorials/job expectations, and scales surprisingly well.

Typical daily commands summary (GitHub Flow style)

Which one feels closest to your current/future job? Want to do a full live simulation of GitHub Flow on a dummy repo? Or dive deeper into feature flags for trunk-based? Or how GitHub Actions fits in modern workflows?

Just tell me — we’ll practice it together step by step. You’re at the point where Git stops being commands and becomes a real superpower! 🚀