合并代码用 merge还是用 rebase?

Merge 合并分支

merge 这种方式应该是大家最熟悉的。merge 会创建一个新的合并提交，将两个分支的历史记录保留在一起。

它的好处是日志保留完整，不管之前有多少提交历史，都会完整地合并到目标分支。

来看看代码示例：

git checkout main
git pull origin main
git merge dev
# 解决冲突后
git commit -m "Merge dev into main"
git push origin main

使用 merge 的好处是非常直观，历史记录完整，看得清楚每次合并和每个提交。

但缺点也是显而易见的，提交历史会显得比较混乱，尤其是在一个团队项目中，各种合并提交一大堆，看着就头疼。

Rebase 合并分支

再来说说 rebase。rebase 会将分支上的更改重新应用在目标分支上，重写提交历史。它最大的特点就是提交历史变得线性，看起来非常干净。

来看一下代码示例：

git checkout dev
git pull origin dev
git rebase main
# 解决冲突后
git rebase --continue
git push origin dev --force

rebase 之后，提交历史看起来就像一条直线，清清爽爽，没有 merge 的那些冗余提交。

但使用 rebase 也有风险，比如说在 rebase 过程中需要处理很多冲突，操作不当还容易搞出大问题。

合并压缩

在 rebase 的时候，还可以用 squash 参数来压缩提交记录。

假设在一个 feature 分支上有多个提交，可以通过 squash 将它们合并成一个提交记录。这样做的好处是进一步简化提交历史。

具体操作如下：

git checkout dev
git rebase -i HEAD~3
# 进入编辑模式后，将 `pick` 改为 `squash`
# 保存并关闭编辑器，编辑新的提交信息并保存
git push origin dev --force

什么时候用 merge，什么时候用 rebase？

到底该用哪种方式呢？这要看具体的场景和你的团队习惯。

使用 merge 的场景：

• 希望保留完整的提交历史
• 适用于多人合作的项目，保留每个人的工作记录

使用 rebase 的场景：

• 希望保持提交历史的简洁和线性
• 适用于希望干净历史的项目

有些公司规定只能用 rebase，因为它更适合单一版本的项目，比如说只有一个主分支一直向前推进。
而对于那些需要维护多个版本的项目，用 rebase 就不太合适了，因为每次 rebase 都会重写提交历史，这在多个分支并行的情况下容易造成混乱。

举个例子，之前参与过一个 Vue 项目，就是用 rebase 来合并分支的。这个项目只有一个主分支，所有的开发都在这个分支上进行，用 rebase 可以保持提交历史的干净整洁。

总结

不管是 merge 还是 rebase，都有其优缺点。选择哪种方式，主要还是看你的项目特点和团队的工作习惯。对于那些刚开始使用 Git 的朋友，不妨多试试这两种方式，找到最适合自己的合并策略。