git merge 命令有什么作用？具体如何使用？

Git Merge 命令详解

【核心定义】

Git merge 命令用于将两个或多个分支的修改历史合并为一个新的提交，实现代码的集成与同步。

【关键要点】

基本作用：合并指定分支到当前分支，创建新的合并提交
使用语法：git merge <branch-name> 将指定分支合并到当前分支
合并类型：
- Fast-forward merge（快进合并）：当目标分支是当前分支的直接后继时
- 3-way merge（三方合并）：当分支出现分叉时，需要创建新的合并提交
冲突处理：当同一文件的同一部分在不同分支有不同修改时，需要手动解决冲突
常用选项：
- --no-ff：强制创建合并提交，即使可以快进合并
- --squash：将多个提交压缩为一个提交再合并
- --abort：中止合并过程，恢复到合并前的状态

【深度推导/细节】

合并算法详解

Step 1 - 寻找共同祖先 Git 首先找到两个分支的最近共同祖先提交（Lowest Common Ancestor, LCA）

Step 2 - 差异计算

计算 LCA 到源分支的差异（A）
计算 LCA 到目标分支的差异（B）

Step 3 - 合并策略选择

快进合并（条件满足时）：

当前分支：A → B → C
要合并的分支：A → B → C → D → E
结果：A → B → C → D → E

三方合并（默认策略）：
- 当分支出现分叉时
- 创建新的合并提交，包含两个父提交

Step 4 - 冲突检测与处理

如果 A 和 B 修改了同一文件的同一区域 → 冲突
如果 A 和 B 修改了不同区域 → 自动合并
如果一方删除文件而另一方修改 → 冲突

合并策略深度解析

Recursive 策略（默认）
- 处理多个共同祖先的情况
- 创建虚拟合并基础
- 适用于大多数合并场景
Ours/Theirs 策略
- -s ours：完全采用当前分支版本
- -X theirs：冲突时采用合并分支版本

【关联/对比】

Git Merge vs Git Rebase

特性	Git Merge	Git Rebase
历史记录	保留分支结构，有合并提交	线性历史，重写提交历史
冲突处理	一次解决所有冲突	可能需要多次解决相同冲突
适用场景	公共分支、团队协作	个人分支整理、保持线性历史
安全性	不重写历史，更安全	重写历史，需谨慎使用

Git Merge vs Git Cherry-pick

Merge：合并整个分支的所有提交
Cherry-pick：选择性合并单个或多个特定提交

『面试官追问』

常见追问问题：

快进合并和非快进合并有什么区别？什么时候用 --no-ff？
- 快进合并：不创建合并提交，直接移动指针
- 非快进合并：总是创建合并提交
- 使用 --no-ff 的场景：
  - 保留分支合并的历史记录
  - 团队协作中明确看到合并点
  - 功能分支合并到主分支时

合并冲突如何解决？具体步骤是什么？

Step 1: git merge feature-branch  # 出现冲突
Step 2: git status                # 查看冲突文件
Step 3: 编辑冲突文件，解决冲突
Step 4: git add <file>           # 标记冲突已解决
Step 5: git commit               # 完成合并

git merge --squash 和普通合并的区别？
- 普通合并：保留所有提交历史
- Squash 合并：将所有提交压缩为一个提交
- 优点：保持主分支历史整洁
- 缺点：丢失详细的提交历史

如何撤销一个合并？

# 方法1：使用 merge 提交的父提交
git reset --hard HEAD~1

# 方法2：使用 merge 提交的哈希
git revert -m 1 <merge-commit-hash>

# 方法3：合并过程中撤销
git merge --abort

递归合并策略如何处理多个共同祖先？
- 当存在多个共同祖先时，递归策略会：
  1. 找到所有共同祖先
  2. 创建虚拟合并基础
  3. 基于虚拟基础进行三方合并
- 这可以处理更复杂的合并场景，如 criss-cross 合并

高级场景分析

场景：合并已合并的分支

# 错误做法：重复合并可能导致冲突
# 正确做法：使用 reflog 或检查合并状态
git log --oneline --graph --all

场景：合并时的文件模式冲突

当文件权限改变（如 644 → 755）时可能产生冲突
解决方案：使用 git config merge.ignoreAllSpace true

【最佳实践建议】

合并前准备

# 1. 确保工作区干净
git status

# 2. 更新本地分支
git fetch origin

# 3. 在目标分支上操作
git checkout main
git merge feature-branch

合并策略选择
- 功能分支 → 开发分支：使用 --no-ff
- 热修复分支 → 生产分支：使用普通合并
- 长期分支同步：定期合并，避免过大差异
冲突预防
- 频繁合并，减少差异积累
- 明确代码所有权和修改范围
- 使用预合并代码审查

合并后验证

# 验证合并结果
git log --oneline --graph --all

# 运行测试
npm test  # 或相应的测试命令

# 必要时回滚
git reset --hard ORIG_HEAD

【版本差异注意事项】

Git 2.9+：默认启用 pull.ff only，需要显式合并
Git 2.18+：改进的合并算法性能
不同 Git 客户端（GitHub Desktop, GitKraken）可能有不同的合并界面和默认行为

通过深入理解 Git merge 的工作原理和使用场景，可以在团队协作中高效管理代码集成，减少冲突，保持项目历史的清晰和可追溯性。

# git merge 命令有什么作用？具体如何使用？