Git 分支管理与合并策略实战指南

合并后查看历史：

lighthouse@VM-8-10-ubuntu:gitcode$ git log --graph --pretty=oneline --abbrev-commit
* ac37cfb (HEAD -> master) merge with no-ff |
* 2bd7b8b (dev2) modify Readme
|/
* cb7ce27 merge book |
* da3c3b1 modify book
* | fc26892 modify book
|/
* 33a5368 modify book

可以看到，不使用 Fast Forward 模式，merge 操作就像下图所示，历史记录中保留了分支信息，而 Fast Forward 合并则无法体现这一点。

二、分支策略

落地到实际项目，分支管理通常遵循几条核心原则：

1. Master 分支：必须非常稳定，仅用于发布新版本，平时禁止直接在上面开发。
2. Dev 分支：日常开发都在此进行，它是不稳定的。
3. 发布流程：当功能成熟（如 1.0 版本）时，再将 dev 分支合并到 master 上。

团队成员各自在 dev 分支上开发，拥有自己的特性分支，定期合并回 dev。团队协作的分支结构大致如下：

三、六种合并策略详解

1. 合并策略全景图

根据使用频率和场景，Git 合并策略分布大致为：Recursive (复杂合并) 占 45%，Fast Forward (快速同步) 占 30%，其余为特殊处理或特定场景。

2. 六大合并策略详解

① Fast Forward（快进合并）

• 触发条件：目标分支没有新提交，可以直接线性推进。
• 命令示例：

  # 强制仅快进合并
  git merge --ff-only dev
  
  # 强制创建合并提交（即使可以快进）
  git merge --no-ff feature/login
  

• 特点：保持线性历史，无额外合并提交，适用于临时特性分支。

② Recursive（递归合并）

这是 Git 的默认策略，处理大多数分叉情况。

• 触发条件：存在分叉提交且需三方合并。
• 命令示例：

  git merge -s recursive -X patience dev
  

• 特点：自动处理多个共同祖先，产生合并提交，覆盖 70%+ 的日常合并场景。

③ Ours/Theirs（选择性合并）

• 触发条件：需要强制保留特定分支内容，常用于架构迁移。
• 命令示例：

  # 正确流程：保留新架构
  git checkout new-arch
  git merge -s ours old-arch
  
  # 危险操作告警：直接覆盖生产分支可能导致数据丢失
  # git checkout production
  # git merge -X theirs staging
  

• 特点：人工指定冲突解决方案，高风险操作，可能覆盖代码。

④ Octopus（章鱼合并）

• 触发条件：同时合并多个分支。
• 命令示例：

  git merge dev feat hotfix
  

• 特点：仅限无冲突合并，常用于 CI/CD 流水线，历史记录最简洁。

⑤ Subtree（子树合并）

• 触发条件：合并外部仓库到子目录。
• 命令示例：

  git merge -s subtree --allow-unrelated-histories external-repo
  

• 特点：保留外部仓库独立历史，自动处理路径冲突，适合组件化开发。

⑥ Resolve（解决合并）

• 触发条件：简单分叉合并（Git 早期版本常用）。
• 命令示例：

  git merge -s resolve legacy-branch
  

• 特点：仅处理单共同祖先，比 recursive 更快，但逐渐被淘汰。

3. 策略对比矩阵

4. 实战场景推荐

1. 功能开发：Recursive（默认） + --no-ff 保留合并痕迹。
2. 紧急修复：Fast Forward 快速上线。
3. 架构迁移：Ours 策略保留新架构。
4. 多特性发布：Octopus 一次合并多个已验证分支。
5. 组件更新：Subtree 管理子仓库。
6. 遗留系统：Resolve 处理简单合并。

5. 高级调试技巧

# 查看可用的合并策略
git merge -s help

# 显示合并细节（调试用）
git merge --verbose --stat -m "合并日志"

# 分析合并基准
git merge-base --all master dev

# 可视化合并过程
git mergetool -t meld

分支治理规范建议：

1. 黄金法则：main 分支必须使用 --no-ff 合并，确保历史可追溯。
2. 权限控制：保护分支禁止使用 theirs 策略，防止误覆盖。
3. 合并检查清单：
   • ✅ 代码评审完成
   • ✅ CI 流水线通过
   • ✅ 文档同步更新
   • ✅ 兼容性测试报告

合并策略决策逻辑：

• 是否落后？是 → Fast Forward
• 有多个共同祖先？是 → Recursive with patience
• 需要强制覆盖？是 → Ours/Theirs
• 合并多个分支？是 → Octopus
• 合并子目录？是 → Subtree
• 否则 → Resolve

实际开发中需要根据项目需求选择最合适的合并方式。建议在团队中制定《合并策略规范》，例如长期分支强制使用 --no-ff，第三方库必须用 subtree 等，以保持代码库的健康度。