Git分支合并的方式

Git 分支合并的方式有merge和rebase两种方式，以下是 git merge 与 git rebase 的深度剖析，从底层原理到实操场景的全面对比：

---

⚙️ ​一、核心原理对比​

​1. git merge（合并）​​

• ​原理​：
  • ​三路合并​：从共同祖先（Common Ancestor）开始到当前分支（HEAD）和目标分支（Feature）的最新提交的所有提交一起进行比较合并，并在把该合并在当前分支生成新的提交​（Merge Commit）。
  • ​保留原始拓扑​：创建新节点连接两个分支，历史记录呈现分叉与汇合。
  • 如下图main分支和bugFix分支的共同祖先C1，在main分支下执行 git merge bugFix 后，将bugFix的提交节点C2和和main的提交节点C3进行比较合并，在main分支下提交了一个新的合并节点C4，bugFix分支保持不变

​2. git rebase（变基）​​

• ​原理​：
  • ​重演提交​：将当前分支的从共同祖先开始的所有提交全部“复制”到目标分支（如 main）的最新提交之后，​丢弃原提交并生成新提交（Commit ID 改变）。
  • ​线性历史​：目标分支的提交历史被“嫁接”到主分支上，形成直线。
  • 如下图，main分支和bugFix分支的共同祖先C1，在bugFix分支执行git rebase main后，将bugFix分支下从共同祖先C1开始的所有提交C2和C3全部“复制”到目标分支main的最新提交C4之后，man分支保持不变，bugFix变基到mian分支之后

🔑 ​本质区别​：

• merge 是保留历史的合并​（新增节点）
• rebase 是重写历史的移动​（复制+丢弃原提交）

---

🛠️ ​二、实操命令与流程​

​1. git merge 操作​

# 切换到主分支
git checkout main

# 合并 feature 分支（默认创建合并节点）
git merge feature

# 强制生成合并节点（禁用快进）
git merge --no-ff feature

# 冲突解决后继续
git add .
git merge --continue

​2. git rebase 操作​

# 切换到 feature 分支
git checkout feature

# 将 feature 变基到 main 分支
git rebase main

# 冲突解决步骤：
# 1. 手动解决冲突文件
# 2. git add <file>
# 3. git rebase --continue

# 若中途放弃：
git rebase --abort

⚠️ ​注意​：

• rebase 后需强制推送​（git push -f），因为提交历史被重写（仅限私有分支！）
• 公共分支禁止 rebase！

---

⚖️ ​三、适用场景与决策树​

​场景​	​推荐操作​	​原因​
​个人本地分支同步主分支​	git rebase main	保持提交历史线性，避免无意义合并节点
​团队协作的公共分支合并​	git merge	保留完整合并历史，避免重写提交导致协作混乱
​整理零碎提交（未推送）​​	git rebase -i	交互式变基可合并/修改提交（squash, fixup）
​发布正式版本​	git merge --no-ff	显式保留合并节点，便于追溯功能集成点

---

💥 ​四、冲突处理差异​

​阶段​	git merge	git rebase
​冲突发生时机​	一次性解决所有冲突​	按提交逐个解决冲突​
​解决流程​	修复 → add → merge --continue	修复 → add → rebase --continue
​复杂度​	低（单次处理）	高（可能需多次重复解决相同冲突）

✅ ​Rebase 冲突技巧​：
使用 git rerere（Reuse Recorded Resolution）自动记住冲突解决方案：

git config --global rerere.enabled true

---

🚫 ​五、禁止操作与风险控制​

1. ​绝对禁止​：
   • 对已推送到远程公共分支执行 rebase（历史重写会破坏他人分支）。
2. ​高风险操作​：
   • rebase 含合并提交的分支（用 git rebase -p 保留合并节点，但复杂易出错）。
3. ​补救措施​：
   • 误操作后通过 git reflog 找回原始提交。

---

💎 ​六、黄金实践总结​

1. ​分支策略​：
   • ​个人开发分支​ → 定期 rebase main
   • ​功能合并到主分支​ → merge --no-ff
2. ​冲突预防​：
   • 合并前执行 git pull --rebase（相当于 fetch + rebase）
3. ​历史查看​：
   • 合并后使用 git log --graph --oneline 验证拓扑结构

​最终决策原则​：

• ​历史真实性​ → 选 merge
• ​提交整洁性​ → 选 rebase（限私有分支）
• 团队必须统一规则！