什么是 Git 的合并操作？有什么作用？

Git 合并操作详解

【核心定义】

Git 合并（Merge）是将两个或多个分支的提交历史整合到一起，生成一个新的提交（合并提交），从而将不同分支的开发成果统一到主线的核心操作。

【关键要点】

数据结构基础：Git 使用有向无环图（DAG）存储提交历史，每个提交包含指向父提交的指针，合并操作本质上是创建具有多个父节点的新提交节点。
核心算法类型：
- 快进合并（Fast-forward）：当目标分支是源分支的直接祖先时，只需移动分支指针，不创建新提交
- 三方合并（3-way Merge）：当分支出现分叉时，基于共同祖先、当前分支和目标分支进行差异分析
递归策略：默认的合并策略，能处理多个共同祖先的复杂情况，通过虚拟合并生成最终合并基础
冲突处理机制：当同一文件同一位置在不同分支有不同修改时，Git 会暂停合并，要求手动解决冲突

【深度推导/细节】

合并冲突的产生与解决逻辑

Step 1 - 冲突检测： Git 比较共同祖先（Base）、当前分支（Ours）和目标分支（Theirs）的同一文件

如果 Base→Ours 和 Base→Theirs 修改了不同区域 → 自动合并
如果修改了同一区域但内容相同 → 自动合并
如果修改了同一区域且内容不同 → 标记为冲突

Step 2 - 冲突标记：

<<<<<<< HEAD (当前分支修改)
当前分支的内容
=======
目标分支的内容
>>>>>>> branch-name

Step 3 - 解决流程：

编辑文件，删除冲突标记，保留正确内容
git add <file> 标记为已解决
git commit 完成合并提交

扩容/保护机制

合并提交的不可变性：一旦创建合并提交，其内容哈希即确定，确保历史完整性
预合并检查：git merge --no-commit 允许先检查合并结果再提交
中止机制：冲突时可通过 git merge --abort 完全回退到合并前状态

【关联/对比】

Git Merge vs Git Rebase

特性	Merge	Rebase
历史记录	保留原始分支结构，创建合并提交	重写历史，形成线性提交序列
冲突处理	一次性解决所有冲突	可能需多次解决相同冲突（每个提交）
适用场景	公共分支、需要保留完整历史	本地分支整理、保持主线整洁
安全性	非破坏性操作	重写历史，对已推送分支危险

Git Merge vs Git Cherry-pick

Merge：整合整个分支的所有更改
Cherry-pick：选择性应用单个提交，不建立分支关联

【线程安全与版本控制】

Git 的并发模型：Git 本身是单线程操作，通过文件锁机制保证仓库数据一致性
合并的原子性：合并操作要么完全成功（生成新提交），要么完全失败（回退原状态）
版本差异：
- Git 1.5.3+：引入递归合并策略，解决复杂合并场景
- Git 2.9+：git merge --no-ff 成为团队协作推荐实践
- Git 2.18+：改进合并冲突提示信息，增加 --show-current-patch 选项

【直击痛点：关键数字与设计】

0.75 - 合并策略的权衡

Git 默认采用递归合并而非简单三方合并，因为：

递归合并能处理超过 2 个共同祖先的复杂情况
通过虚拟合并创建”虚拟共同祖先”，提高合并准确性
虽然计算复杂度从 O(n) 增至 O(n²)，但对现代硬件影响可忽略

3 - 三方合并的必要性

为什么需要三方（Base, Ours, Theirs）而不是两方比较？

场景示例：文件在祖先版本为空，A 分支添加了内容，B 分支删除了文件
两方比较：A vs B → 完全冲突（添加 vs 删除）
三方比较：Base(空) → A(添加) vs Base(空) → B(删除) → 正确识别为”添加与删除冲突”
结论：三方合并能准确识别”各自做了什么”，避免误判

『面试官追问』

快进合并什么情况下会发生？如何强制创建合并提交？
- 答：当目标分支是当前分支的直接祖先时发生。使用 git merge --no-ff 强制创建合并提交，即使满足快进条件。
递归合并策略如何处理多个共同祖先？
- 答：递归合并会先虚拟合并这些共同祖先，生成一个”虚拟合并基础”，再以此为基础进行最终合并。例如分支 A 和 B 都从 master 分出，但 A 先合并了 master 的新提交，此时 B 合并 A 就有多个共同祖先。
合并冲突时，如何查看某个文件的三个版本（共同祖先、当前、目标）？
- 答：使用 git show :1:filename（祖先）、:2:filename（当前）、:3:filename（目标）。或使用 git mergetool 可视化工具。
git merge 和 git pull 的关系是什么？
- 答：git pull = git fetch + git merge。git pull --rebase = git fetch + git rebase。默认情况下 pull 使用 merge 策略。
如何撤销一个已完成的合并？
- 答：如果合并已提交但未推送：git reset --hard HEAD~1（如果合并是最近提交）。更安全的方式：git revert -m 1 <merge-commit-hash> 创建反向提交，其中 -m 1 指定保留第一个父分支线。
Octopus 合并策略是什么？何时使用？
- 答：用于一次性合并三个或更多分支的策略。当需要将多个特性分支同时合并到主分支时使用，但只能在没有冲突的情况下工作。命令：git merge branch1 branch2 branch3。
合并时如何忽略空白字符差异？
- 答：使用 git merge -Xignore-space-change 或 -Xignore-all-space。-X 选项传递策略选项给合并策略。
什么是”ours”和”theirs”合并策略？
- 答：-s ours：创建合并提交但完全采用当前分支内容，忽略目标分支。-X ours：冲突时自动选择当前分支版本（递归策略的选项）。前者是整个合并策略，后者是冲突解决偏好。

最佳实践总结：

主分支合并使用 --no-ff 保留合并历史
合并前先更新本地分支（git fetch + git merge origin/branch）
复杂合并使用 git merge --no-commit 预先检查
长期运行的分支定期 rebase 到主分支，减少最终合并冲突
团队统一合并策略，特别是冲突解决规则

通过理解 Git 合并的底层图论基础和多种策略机制，开发者可以更自信地处理各种分支整合场景，确保项目历史的清晰与完整。

# 什么是 Git 的合并操作？有什么作用？