Branch Strategies — Picking Your Workflow
The Campus Library team already learned two routines in Workflows. Real teams formalize that into a branch strategy — a shared agreement on how branches are created and merged. Here are the three most common ones.
1 · Git Flow — For Scheduled Releases
The classic heavyweight. Multiple long-lived branches: main, develop, plus feature/*, release/*, and hotfix/* branches.
- develop is where features land;
mainonly holds releases. release/*branches prepare a version;hotfix/*patch production quickly.- Best for: software with big, planned releases (mobile apps, packaged software).
2 · GitHub Flow — For Continuous Delivery
The lightweight champion. One protected main, short-lived feature branches merged via Pull Requests.
- Anything on
mainis deployable, always. - Open a branch → commit → push → open a Pull Request → review → merge.
- Best for: teams shipping continuously (websites, SaaS, startups).
3 · Trunk-Based Development — For Small, Fast Teams
Everyone works directly on main (the trunk) with very short branches, often merging multiple times a day.
- Conflicts are rare because branches are tiny.
- Often combined with feature flags to hide unfinished work.
- Best for: small senior teams, continuous integration purists.
Which One for You?
| Git Flow | GitHub Flow | Trunk-Based | |
|---|---|---|---|
| Release style | Scheduled big releases | Continuous delivery | Continuous integration |
| Branch count | Many, long-lived | One long + short features | Mostly just main |
| Review process | Merge to develop, then release | Pull Request on every feature | Direct commits / pair review |
| Team size | Large / distributed | Small to medium | Small & experienced |
| Conflict risk | Lowest (isolated) | Low | Low if branches are tiny |
Five students, one app, fast iteration → choose GitHub Flow. It's simple, keeps main always working, and its Pull Request ritual is exactly how you'll contribute to open source later.
Move to Git Flow only if the project grows into scheduled releases. Avoid trunk-based until the whole team is very comfortable.
The "best" strategy is the one the team agrees on and follows. Consistency beats cleverness — even GitHub Flow done badly loses to any strategy done well.
Back to the Workflows that introduced you to these ideas, or test your knowledge with the Check Your Understanding quiz.