Git分支管理实战指南：从混乱到有序，5个策略搞定团队协作
上周有个朋友找我救火。他的团队有12个人，Git仓库里有300多个分支，git branch 输出来能滚屏三页。有人直接在 main 上改代码，有人合并完忘了删分支，还有人把一个功能拆成五个分支各干各的。
我说你这不叫开发，这叫行为艺术。
分支管理看着是个小问题，实际上决定了整个团队的开发效率和代码质量。管得好，合并像喝水一样自然。管不好，每天都在解决 merge conflict，头发一把一把掉。
今天我把踩过的坑整理成这篇实战指南。不讲虚的理论，直接上命令、上策略、上案例。
一、先搞清楚：你们团队在用哪种分支策略？
市面上主流的分支管理策略就三种。选错了，后面全乱。
1. Git Flow：适合传统发布周期
这是 Vincent Driessen 在2010年提出的经典模型。核心思想是：main 和 develop 两条主线并行，功能开发走 feature 分支，发布前走 release 分支，修bug走 hotfix 分支。
main ────────○──────────────○─────── 发布版本
╲ ╱
release-1.0 release-2.0
╲ ╱
develop ──○──○──○────── 持续集成
╲ ╱ ╲ ╲
feature-A feature-B
优点：结构清晰，适合有固定发布周期的项目（比如桌面软件、移动App）。
缺点：分支太多，维护成本高。一个小功能也要走完整的 feature → develop → release → main 流程，慢。
适用场景：版本号明确、发布周期固定的项目。
2. GitHub Flow：简单粗暴
只有一条 main 分支。要做新功能？拉个分支。做完？提交PR。审核通过？合并到 main。然后直接部署。
main ────────○──────────────○─────── 实时部署
╲ ╱
feature-A feature-B
优点：极简。没有 develop 分支，没有 release 分支，没有 hotfix 分支。新人半天就能上手。
缺点：main 必须随时可部署。如果你的 CI/CD 不够完善，合并一个有 bug 的代码就会直接上线炸掉。
适用场景：持续部署的 Web 项目、SaaS 产品。
3. Trunk-Based Development：大厂玩法
几乎所有分支都叫 trunk（主干）。每个人在 trunk 上工作，短期分支（存活不超过一天）做实验性改动。配合 feature flag 来控制功能上线。
trunk ──○──○──○──○──○──○──○── 持续集成+Feature Flag
│ │ │ │ │ │
feat-A feat-B feat-C
优点：最快。没有长期分支，merge conflict 几乎不存在。
缺点：需要强大的 CI/CD 和 feature flag 基础设施支撑。小团队玩不起。
适用场景：大厂级别的持续交付团队。
二、5个实战策略，让你的分支管理不再混乱
不管选哪种策略，下面这5条规则是通用的。
策略1：分支命名要有规范
别再用 test、new、fix 这种名字了。别人看到你的分支名，应该一眼就知道你要干什么。
推荐格式：{类型}/{编号}-{简短描述}
git checkout -b feature/123-user-login
git checkout -b fix/456-payment-timeout
git checkout -b refactor/789-db-query
类型说明：
feature/：新功能fix/：bug修复refactor/：代码重构docs/：文档更新chore/：杂务（依赖升级、配置修改等）
策略2：定期清理废弃分支
这是我最头疼的问题。很多人合并完代码，忘了删分支。仓库里堆了几百个僵尸分支，git branch -a 一看就想吐。
加个定时清理脚本：
# 删除已合并到 main 的本地分支
git branch --merged main | grep -v "^\*" | xargs -n 1 git branch -d
# 删除已合并的远程分支
git fetch --prune
git branch -r --merged origin/main | grep -v 'HEAD' | awk '{print $1}' | xargs -I {} git push origin --delete {}
建议在 CI 流程里加一步：每次 push 到 main 时自动清理已合并分支。
策略3：小步提交，频繁合并
不要在一个分支上干一周的活。分支越长，合并时的冲突越多。
我的原则：每次提交只做一件事，每个分支最多活3天。
# 错误做法：一个分支改了10个文件，提交一次
git commit -m "fix everything"
# 正确做法：拆成多次提交
git add src/auth/login.ts
git commit -m "feat: add login form validation"
git add src/auth/session.ts
git commit -m "feat: implement session management"
git add tests/auth.spec.ts
git commit -m "test: add auth unit tests"
策略4：合并前必须先 rebase
rebase 是让提交历史保持线性的最佳手段。合并前先 rebase 到最新的主分支，可以避免无意义的 merge commit。
# 在 feature 分支上
git checkout feature/user-login
git rebase main
# 如果有冲突，解决后继续 rebase
git add .
git rebase --continue
# 确认没问题后，再合并回 main
git checkout main
git merge feature/user-login
rebase 之后，你的提交历史是一条漂亮的直线，而不是蜘蛛网。
策略5：强制 PR/MR 审核
不管团队多小，合并到 main 之前必须经过至少一个人审核。这不是不信任，是防止手滑。
如果用的是 GitHub，可以在仓库设置里开启 Branch Protection Rules：
- 要求至少1个 reviewer 批准
- 要求通过 CI 检查
- 禁止 force push 到 main
- 禁止直接 push 到 main
三、真实案例：我们团队是怎么从混乱到有序的
去年我们团队从5个人扩展到20个人，Git 仓库直接炸了。
当时的情况：
- 150+ 未清理的分支
- 每周至少3次 main 分支冲突
- 有两次因为合并错误导致线上服务挂了半小时
我们做了三件事：
第一，统一采用 GitHub Flow。砍掉 develop 分支，砍掉 release 分支。main 就是唯一的生产分支。
第二，推行分支命名规范和 rebase 策略。写进团队文档，新人入职第一天就学。
第三，开启分支保护规则。没有人能绕过 PR 直接推代码到 main。
三个月后：
- 活跃分支数降到20以内
- 合并冲突减少了90%
- 线上事故从每月2-3次降到0次
变化不是魔法，是纪律。
四、常用分支操作速查表
把这张表存下来，遇到分支问题直接查。
# 查看当前所有分支
git branch -a
# 查看哪些分支已合并到 main
git branch --merged main
# 查看哪些分支未合并（危险！可能丢失代码）
git branch --no-merged main
# 切换分支
git checkout main
git switch feature/user-login # 新版语法
# 创建并切换到新分支
git checkout -b feature/new-ui
git switch -c feature/new-ui
# 删除本地分支
git branch -d feature/old-feature
git branch -D feature/force-delete # 强制删除（未合并的）
# 删除远程分支
git push origin --delete feature/old-feature
# 查看分支的提交历史
git log main..feature/user-login --oneline
# 查看两个分支的差异
git diff main..feature/user-login
# 交互式 rebase（最后N次提交）
git rebase -i HEAD~5
# 撤销最近一次提交（保留改动）
git reset --soft HEAD~1
# 撤销最近一次提交（丢弃改动）
git reset --hard HEAD~1
五、总结：分支管理的本质是纪律
好的分支管理不需要复杂的工具，只需要三样东西：
- 清晰的规则——团队所有人都知道该怎么命名、怎么提交、怎么合并
- 自动化的检查——CI/CD 帮你拦住不合规范的代码
- 定期的维护——每周清理一次废弃分支，养成习惯
你现在用的分支策略是什么？有没有被 merge conflict 折磨过？评论区聊聊你的踩坑经历。