Git Flow Strategy
When to Use
- Deciding which branch to base work on.
- Creating a new Release or Hotfix.
- Merging strategies (Squash vs Merge Commit).
1. Branching Model
| Branch | Source | Merge Into | Lifespan | Purpose |
| ----------- | --------- | ----------------- | ---------- | ------------------------------------------------- |
| main | - | - | Infinite | Production-ready code. Stable. |
| develop | main | main | Infinite | Integration branch for next release. |
| feature/* | develop | develop | Short | New features (e.g., feature/login-page). |
| release/* | develop | develop, main | Medium | Release prep (e.g., release/v1.0.0). |
| hotfix/* | main | develop, main | Very Short | Production critical fixes (e.g., hotfix/crash). |
2. Feature Development
- Start: Update
developand branch off.git checkout develop && git pull origin develop git checkout -b feature/my-feature - Work: Commit changes. Use
githubskill templates for PRs. - Finish: PR into
develop. Squash merge recommended.
3. Release Process
- Start: Branch off
developwhen features are frozen.git checkout develop git checkout -b release/v1.2.0 - Work: Bump versions, update changelogs, fix bugs. NO NEW FEATURES.
- Finish:
- Merge into
main(Tag this commit). - Merge into
develop(Back-propagate fixes). - Delete
release/v1.2.0branch.
- Merge into
4. Hotfixes
- Start: Branch off
main(Production).git checkout main git checkout -b hotfix/critical-bug - Work: Fix the critical bug. Minimal changes.
- Finish:
- Merge into
main(Tag this commit). - Merge into
develop. - Delete
hotfixbranch.
- Merge into
5. Protocols
- Never commit directly to
mainordevelop. - Keep history clean. Use interactive rebase before PRs.
- Tags are immutable. Once pushed, do not change.