你在公司写代码，同事也在改同一块功能，结果一合并，代码冲突一堆，功能还出bug。这种情况太常见了，其实问题不在代码水平，而在分支没管好。
为什么需要分支策略
想象你在家装修，一边刷墙一边铺地板，工人来回踩踏，最后两头都干不好。软件开发也一样，新功能开发、线上bug修复、版本发布如果都在一条线上搞，肯定乱套。Git分支就是帮你把不同工作隔开，各干各的互不干扰。
主流分支模型：Git Flow 简化版
很多人一听Git Flow就觉得复杂，其实核心就几条：
- main 分支：只放能上线的稳定代码
- develop 分支：日常开发集成用的“中转站”
- feature 分支：每人开发新功能从develop拉出来，做完再合回去
- hotfix 分支：线上出问题，直接从main拉分支修，修完两边都合
比如你负责加个用户登录功能，先从develop切个分支：
git checkout -b feature/user-login develop写完测试通过后，提个PR（Pull Request）合并回develop。这时候别人也在提交，但你的功能不会被中途打断。
小团队更适用的：Trunk-Based Development
如果你是小团队，或者做持续交付，可以更简单。所有人主要在 main 上开发，功能没完成就用开关控制（Feature Flag），避免影响线上。
比如你正在写个新支付流程，但还没测完，就在代码里加上判断：
if (featureFlags.isEnabled("new_payment_flow")) {
startNewPayment();
} else {
startOldPayment();
}这样代码可以直接进主干，但功能对用户不可见。等准备好了，关掉开关就行，不用再折腾分支合并。
实际操作建议
分支命名别随便来。用 feature/、bugfix/、hotfix/ 开头，一眼就知道是干啥的。比如：
git checkout -b bugfix/order-status-update main提交记录也要清晰，别写“改了点东西”这种。写清楚改了什么，比如“修复订单状态未同步问题”。
合并时尽量用 git merge --no-ff，保留分支历史，以后查问题方便。你三个月后再看，还能知道当初这个功能是谁、什么时候、为啥做的。
分支别赖着不删。功能上线后，本地和远程的旧分支及时清理，不然仓库里几百个分支，谁看得懂。