你有没有遇到过这种情况：团队里好几个人同时改代码，一合并就冲突，改着改着发现功能丢了，甚至上线版本出了问题都找不到源头？别说你没碰代码——哪怕只是更新个文案，也可能因为分支搞混，把别人还没测试完的功能一起推上了生产。
为什么需要分支策略？
想象一下厨房做菜。主厨负责出锅前的最终拼盘（相当于生产环境），副厨们各自准备食材、炒菜、摆盘（开发新功能）。如果所有人直接在同一个灶台上操作，那场面肯定乱成一锅粥。分支策略，就是给每个任务划好操作台，最后再有序整合。
常见的 Git 分支模型长啥样？
最典型的要数 Git Flow，虽然现在很多人简化了它，但核心思路依然通用：
- main / master：主分支，只放稳定可发布的代码，对应线上运行的版本。
- develop：日常开发集成分支，所有新功能先合到这里测试。
- feature/*：功能分支，每人或每组开一个，比如
feature/user-login。 - release/*：准备发版时从 develop 拉出，用于测试和修 bug。
- hotfix/*：线上出问题了，紧急修复用，修完直接合并回 main 和 develop。
图解流程是这样的：
假设当前 main 在 v1.0，团队要开发 v1.1：
main: ----v1.0---------------------------
\
\
develop: --a---b---c---d------e--------
\ \
\ \
feature/A release/v1.1 → 测试中
\
f-----g
\
\
hotfix/critical → 紧急修复
\
h
其中：
- f、g 是某个功能的提交，完成后合并进 develop。
- d 是 release 分支切出的节点，之后 develop 继续接收新功能。
- h 是 hotfix 提交，修复完立刻合并到 main（打 v1.0.1）和 develop，避免遗漏。
更轻量的选择：GitHub Flow
不是所有项目都需要这么复杂。如果你是小团队，或者持续交付节奏快，GitHub Flow 更清爽：
- 只有 main 分支，始终可部署。
- 每个需求开一个 feature 分支。
- 写完后提 Pull Request，走代码审查。
- 合并进 main 后自动触发部署。
简单粗暴，适合迭代快的产品，比如运营活动页面、内部工具等。
实际建议：别照搬模板
见过太多团队生搬 Git Flow，结果 release 分支没人管，hotfix 混着功能一起上，最后还不如不分支。
关键是根据项目节奏定规则。比如：
- 两周一次发版？可以用简化版 Git Flow。
- 每天都要上线？直接 GitHub Flow + 自动化测试。
- 多人协作大功能？feature 分支必须配 PR 和 CI 检查。
分支策略不是画出来就完事了，得有人守规则，有工具支持（比如保护 main 分支、自动跑测试），不然图再好看也没用。