我们团队就五个人，做的是一个中型后台管理系统。最开始大家直接在 main 分支上改代码，结果三天两头合并冲突，上线前一查日志，根本分不清谁动了哪儿。后来干脆坐下来商量了一套简单实用的分支策略，跑了几个月，节奏顺多了。
主干清晰，功能开分支
现在我们的 main 分支永远保持可发布状态。任何人不能直接往里推代码。新需求来了，比如要加个「导出报表」功能，就从 main 拉一个 feature/export-report 分支出来。
git checkout main
git pull origin main
git checkout -b feature/export-report这个分支只干一件事，写完测完，提 Merge Request（或 Pull Request），等至少一个人 review 通过，再合回 main。这样主线干净，出了问题也能快速定位。
临时联调？试试临时合并分支
有次前端要联调三个后端接口，分别在不同 feature 分支上。等全部完成再联调太慢，我们就建了个临时分支 feature/integrate-202406，把这三个分支先合并进去。
git checkout feature/integrate-202406
git merge feature/export-report
git merge feature/user-permission
git merge feature/log-search联调没问题后，各自的功能分支再单独合入 main。这个集成分支用完就删，不保留，避免混乱。
上线前冻结，用 release 分支锁版本
每次准备发版，我们都会从 main 切出一个 release/v1.3.0 分支。这时候开发照常进行，但 release 分支只修 bug，不加新功能。
测试在 release 分支上跑，发现问题就在这里提交 hotfix，确认后再同步回 main 和当前开发中的 feature 分支。这样两边进度互不影响。
线上出问题？hotfix 来救场
有天早上刚上班，运营说用户列表打不开。一看是昨天合进去的一个日志中间件抛了空指针。我们立刻从 main 拉了个 hotfix/fix-null-pointer 分支，修完当天第二次发版。
git checkout main
git pull origin main
git checkout -b hotfix/fix-null-pointer
# 修改代码并提交
git add .
git commit -m "fix: prevent null pointer in logger"
git push origin hotfix/fix-null-pointer修复合并后，main 和正在开发的 release 分支都同步更新。整个过程半小时搞定，没影响其他人干活。
别搞太复杂，适合自己才最重要
见过有些团队照搬 Git Flow，光分支类型就五六种，文档写三页，最后没人记得清规则。我们这套其实就是“功能分支 + 发布分支 + 热修复”的组合，轻量，容易记住。
关键是大家都遵守规则，每天开工前 pull 一下，提交前看一眼分支对不对。时间久了，就成了习惯，不再觉得是负担。