Git的三种合并方式

在 Gitee（码云）中合并分支主要有三种方式：​普通合并（Merge Commit）、压缩合并（Squash Merge）​ 和变基合并（Rebase Merge）​。每种方式适用于不同的场景，各有优缺点。以下是详细对比：

---

​1. 普通合并（Merge Commit）​​

​特点​

• 保留完整历史：生成一个新的合并提交（Merge Commit），包含两个分支的所有提交记录。
• 非破坏性操作：不会修改原有提交历史。
• 分支关系清晰：在提交历史中会显示分叉和合并的路径。

​适用场景​

• 需要保留完整开发过程（如多人协作时的分支合并）。
• 合并长期存在的功能分支到主分支（如 dev → master）。

​操作步骤​

1. 在 Gitee 的 Pull Request 页面，选择 ​"普通合并"​。
2. 确认后会自动生成一个类似 Merge branch 'feature' into 'master' 的提交。

​优缺点​

优点	缺点
历史完整可追溯	提交历史可能冗长
操作简单安全	频繁合并会导致提交树复杂，呈现出非线性的结构尤其是在同时合并多个分支的情况下

---

​2. 压缩合并（Squash Merge）​​

​特点​

• 压缩提交记录 ：将分支上的所有提交合并为一个全新提交，丢弃原分支的独立提交历史。
• 简化历史 ：主分支（如 master）的提交记录保持线性、干净。

​适用场景​

• 合并短期功能分支（如修复 Bug 的小分支）。
• 分支提交较多但无需保留中间过程（如临时实验性代码）。

​操作步骤​

1. 在 Pull Request 页面选择 ​"压缩合并"​。
2. 系统会将分支的所有更改压缩成一个提交，并合并到目标分支。

​优缺点​：

优点	缺点
主分支历史简洁	丢失原分支的详细提交记录
避免无关中间提交	不利于后期追踪单次修改的上下文

---

​3. 变基合并（Rebase Merge）​​

​特点​

• 线性历史 ：将分支的提交"重新播放"到目标分支的最新提交之后，不生成合并提交。
• 修改提交历史：原分支的提交哈希会改变（属于破坏性操作）。

​适用场景​

• 需要保持提交历史完全线性（如开源项目的主分支）。
• 本地分支同步主分支更新时常用（需在本地执行 git rebase）。

​注意事项​

• Gitee 的 Web 端不支持直接变基合并 ，需通过命令行操作：

  git checkout feature
  git rebase master
  git checkout master
  git merge feature  # 快进合并（Fast-forward）

​优缺点​

优点	缺点
提交历史线性清晰	操作复杂，容易出错
无多余合并提交	重写历史可能影响协作

---

​三种方式对比总结​

合并方式	提交历史	是否生成合并提交	适用场景
​普通合并​	保留分叉和合并记录	是	长期分支合并，需完整历史
​压缩合并​	压缩为单一提交	是（但只有一个）	简化历史，合并短期分支
​变基合并​	线性历史（无分叉）	否	追求简洁历史，需本地操作

---

​如何选择？​​

1. 团队协作 → 优先用 普通合并（保留上下文）。
2. 临时分支 → 选择 压缩合并（避免无关提交）。
3. 个人项目/开源项目 → 本地 变基合并（保持历史整洁）。