All chapters in this track
- 011. The Mental Model
- 022. Essential Setup
- 033. Core Daily Workflow
- 044. Branching
- 055. Merging & Conflict Resolution
- 066. Rebasing
- 077. Remote Repositories
- 088. Stashing
- 099. Undoing Things
- 1010. Tagging & Versioning
- 1111. Cherry-Pick
- 1212. Git Bisect & Blame
- 1313. Git Hooks
- 1414. Submodules
- 1515. Team Workflows
- 1616. Power Commands & Aliases
- 1717. Reflog: The Safety Net
- 1818. Practice Tasks
- 19Quick Reference Cheatsheet
Chapter 15 of 19
15. Team Workflows
15.1 GitHub Flow (Simple, fast, CI-driven)
Best for: web apps, SaaS, continuous deployment.
main
├── feature/login ← branch off main
│ ↓ (PR + review)
└── merge to main → deploy
Steps:
- Branch off
mainwith a descriptive name - Commit early and often
- Open a Pull Request (PR) when ready for review (or as draft for early feedback)
- CI runs tests, reviewer approves
- Merge to
main— triggers automatic deployment
Key rules: main is always deployable. No long-lived branches.
15.2 Gitflow (Structured release cycles)
Best for: versioned products, mobile apps, enterprise software.
main (production)
develop (integration)
├── feature/x ← branch from develop, merge back to develop
├── release/2.1 ← branch from develop, merge to main + develop
└── hotfix/x ← branch from main, merge to main + develop
| Branch | Purpose |
|---|---|
main | Production-ready only |
develop | Integration branch |
feature/* | New features (branch from develop) |
release/* | Prep for release — only bug fixes, docs |
hotfix/* | Emergency fix on production |
# Feature
git switch -c feature/login develop
# ... work ...
git switch develop
git merge --no-ff feature/login
# Release
git switch -c release/2.1 develop
# bump version, fix last bugs
git switch main ; git merge --no-ff release/2.1 ; git tag -a v2.1.0
git switch develop ; git merge --no-ff release/2.1
# Hotfix
git switch -c hotfix/payment main
# fix bug
git switch main ; git merge --no-ff hotfix/payment ; git tag -a v2.1.1
git switch develop ; git merge --no-ff hotfix/payment
15.3 Trunk-Based Development (TBD)
Best for: experienced teams with strong CI/CD, Google/Facebook style.
main (trunk) ← everyone commits here directly or via very short-lived branches
Rules:
- Branches live ≤ 1-2 days (or commit directly to main)
- Feature flags hide incomplete features in production
- CI must be fast and run on every commit
- No long-lived branches — they're the enemy of TBD
# Short-lived branch style
git switch -c feature/header-cta
# finish in <2 days
git rebase main # keep up-to-date
git push origin feature/header-cta
# immediate PR + merge
Workflow Comparison
| GitHub Flow | Gitflow | Trunk-Based | |
|---|---|---|---|
| Release cadence | Continuous | Scheduled | Continuous |
| Branch lifetime | Days | Weeks | Hours |
| Complexity | Low | High | Low |
| Best for | Web apps | Versioned releases | Experienced teams |