代码分支管理策略
# 代码分支管理策略
GitFlow/Trunk-based、cherry-pick——分支策略决定协作效率
# 一、分支策略不是选哪个好看——是选哪个不痛苦
两种主流策略的本质对比：
GitFlow：
master ────┬───────┬──── (生产代码)
│ │
develop ───┼──┬──┬─┼──┬── (开发主线)
│ │ │ │ │
feature/A ┘ │ │ │ │ (功能分支，从 develop 拉，合回 develop)
feature/B ┘ │ │ │
release/1.2 ┘ │ │ (发布分支，从 develop 拉，合到 master + develop)
hotfix/1.2.1 ┘ │ (热修复，从 master 拉，合到 master + develop)
Trunk-based（主干开发）：
main ──┬─────┬─────┬───── (唯一的长期分支)
│ │ │
feat/A─┘ │ │ (短功能分支，最多存在 1-2 天)
feat/B───────┘ │
feat/C─────────────┘
# 选型决策
| 场景 | 推荐策略 | 原因 |
|---|---|---|
| 5 人以下小团队，每天发版 | Trunk-based | 分支少，合并快，最简洁 |
| 10-50 人，有固定发布周期 | 简化 GitFlow（不要 develop） | 去掉 develop 层，master + feature + release |
| 维护多个版本（如 v1.x 有客户用，v2.x 在开发） | 完整 GitFlow | release 和 hotfix 分支能管理多版本并行 |
| 开源项目，外部贡献者多 | GitHub Flow（Trunk-based 变体） | 所有 PR 往 main 提，靠 CI + Review 保证质量 |
90% 的团队不需要 GitFlow 的全部复杂性。 如果你从未同时维护过 3 个以上活跃版本——你在用一个你不需要的复杂度。
# 二、简化 GitFlow——只保留四个分支类型
master ：生产代码。只接受 release 和 hotfix 的合并。
feature/* ：新功能。从 master 拉，合回 master。（活 1-5 天）
release/* ：发布候选。从 master 拉，修 bug 后合回 master + tag。
hotfix/* ：紧急修复。从 master 拉，修完合回 master + tag。
去掉 develop 分支：develop 在大多数团队的真正作用是"延迟合并到 master 的缓冲区"。如果你有 CI + code review ——合到 master 就是安全的，不需要 develop 来缓冲。
# 三、合并策略——merge vs rebase vs squash
Merge（保留完整历史）：
master: A → B → C → M （M 是 merge commit）
feature: D → E ────┘
→ 分支结构清晰，但历史里有很多分叉
Squash and Merge（把整个 feature 压成一个 commit）：
master: A → B → C → D' （D' 包含了 D+E 的全部改动）
→ master 历史是干净的线性，但丢了 feature 内部的细分 commit
Rebase and Merge（线性历史，保留细分）：
master: A → B → C → D → E （D 和 E 被挪到了 C 后面，hash 变了）
→ 历史干净，但 rebase 有风险（多人协作同一个 feature 分支时会翻车）
实战选择：
对 master 分支：永远只用 Merge 或 Squash Merge —— 不要 rebase master
对 feature 分支：
你一个人在做 → rebase 到 master 再提 PR（保持线性历史）
多人在做 → merge master 进 feature（安全，不改变已推送的 commit）
# 四、cherry-pick ——能用但不要滥用
cherry-pick 是把一个 commit 单独挑出来，嫁接到另一个分支上。听起来很灵活——但那是因为你不知道它有多危险。
cherry-pick 能用的场景：
→ 在 release/1.2 上修了一个 bug，需要同步到 master
→ 从 release 分支 cherry-pick 这个 fix commit 到 master
cherry-pick 不该用的场景：
→ "我只想上线 feature 的一半，另一半下次再说"
→ cherry-pick 了 commit A 但没 pick commit B（A 依赖 B）
→ 上线后报错，原因是你只搬了代码没搬它的前置修改
规则：如果同一个 bug fix 需要放到多个分支——cherry-pick。如果同一个功能要拆成两部分上线——不要 cherry-pick，用 Feature Flag 控制。
# 五、分支命名的约定
feature/user-login → 功能分支
bugfix/fix-payment-null → bug 修复分支
hotfix/2024-01-15-crash → 紧急修复（带上日期）
release/1.3.0 → 发布分支
chore/update-deps → 杂务（升级依赖、改 CI 配置等）
命名铁律：分支名字一看就知道它在做什么，删除时不犹豫。三个月后你看到 fix-bug 和 fix-payment-timeout-on-null-user —前者你敢删吗？不敢，因为你不知道它修的是什么。
# 六、分支保护的底线配置
master 分支必配的保护：
□ 禁止直接 push（必须通过 PR）
□ 至少 1 个人 approve 才能合并
□ CI 必须通过（自动化测试全绿）
□ PR 必须和 master 无冲突（冲突需要手动 rebase/merge 解决）
□ 不允许 force push
可选的加强：
□ 特定目录的改动需要特定人员 approve（如 db/migrations/ 需要 DBA 审批）
□ PR 标题必须符合 conventional commits 格式
为什么需要分支保护：不是不信任同事——是深夜 2 点你觉得"就改一行直接 push 吧"，第二天早上线上挂了，没人知道你改了哪一行。
# 六、常见灾难场景及预防
# 6.1 场景一：合并冲突地狱
三天的 feature 分支，合并时发现 20 个文件冲突——手动解决了一天。
预防：每天从主分支 rebase 一次。冲突越晚处理越大。Feature 分支的生命周期不超过 3 个工作日——超过就拆。
# 6.2 场景二：hotfix 合入了不该合的东西
hotfix 分支修了支付 bug，顺便把下个版本的代码也带进来了——主分支崩了。
预防：hotfix 从 master 切出、合回 master 和 develop。hotfix 上只修这一个 bug——不要"顺便"干别的事。
# 6.3 场景三：release 分支的漏合
在 release 上修了个 bug，忘了同步回 develop——下次发版 bug 又回来了。
预防：release 分支合入 master 后，立即 merge 回 develop。如果忘了，72 小时内发现并补合——超过 72 小时 develop 已经变了太多，漏合更难处理。
# 七、mono repo vs multi repo 的分支策略
| mono repo | multi repo | |
|---|---|---|
| 分支模型 | 所有服务共享一套分支 | 每个仓库独立分支 |
| 发版 | 可以统一发版，但任何模块的变更都会触发全量 CI | 独立发版，节奏灵活 |
| 分支数量 | 少（只有 main + feature） | 多（每个仓库至少 main + feature × N） |
| 适合 | 强耦合的微服务、共享代码多的团队 | 独立演进的微服务、多语言异构系统 |
不论 mono 还是 multi：main/master 分支永远可部署——这是不可妥协的铁律。
# 八、小结
分支策略选择：
小团队、快迭代 → Trunk-based
中大型团队 → 简化 GitFlow
多版本并行维护 → 完整 GitFlow
三条铁律：
1. Master 永远可部署
2. 分支命名一眼可辨
3. Cherry-pick 只用于跨分支同步 fix
4. Feature 分支不超过 3 天——超过就拆
5. hotfix 从 master 切，只修一个 bug
行动清单：
- [ ] 检查 master 有没有保护规则
- [ ] 超过 2 周没更新的分支——删掉
- [ ] 团队对齐：merge commit 还是 squash？所有人同意吗？
- [ ] 有没有 feature 分支活了超过一周？——拆成小 PR
