大家好，我是谦！

你们平时合并代码时用 merge 还是 rebase？我私下问了一圈，发现有些人不仅没用过 rebase，甚至压根没听说过这个命令。

别紧张，这没什么大不了的！不用 rebase 完全不影响日常开发、分支合并甚至项目发布。我自己用 Git 很久也根本不知道 rebase 的存在，一直以为合并分支就只有 merge 这一种方式，直到一位新入职的同事问我：“为什么不用 rebase 来合并分支呢？我上一家公司基本都用 rebase，很少用 merge。”那是我第一次听说 rebase 这个命令。

实则 merge 和 rebase 只有在需要合并分支时才会被讨论。如果项目没有分支合并的需求，那用什么方式都无所谓。列如我自己的个人小项目，从头到尾只有一条 main 分支，开发者也只有我一个，根本没有冲突可言，有时写好几天都不需要 push 一次。

而真正需要处理分支合并的，大多是多人协作的团队项目。这类项目一般会有一个主分支，再加上开发分支，有时还会出现一些临时性的 feature 分支。

merge 合并分支

即使在同一个分支内，也可能发生 merge 操作。例如，我负责的一个老项目平时很少有其他人改动，因此在修改时容易疏于先执行 pull 操作——这当然是一个不良习惯。结果有时一 push 代码，才发现已有其他人提交了新内容，此时便会自动触发一次 merge。

本文重点探讨的是跨分支合并场景下的 merge 操作。下图展示了使用 merge 合并分支前后，版本变化的情况。

merge 操作会创建一个新的合并提交节点，完整保留两个分支的历史记录。其核心特点是提交日志的完整性——无论被合并的分支包含多少次提交，所有历史均会完整并入目标分支。下图展示了使用 merge 合并后的主分支版本图谱，其结构呈现出典型的多线交织特征。

假设有两个分支，main 和 dev分支，在 dev 分支上开发，然后合并到 main 分支，合并的大致流程如下。

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

Rebase 合并分支

rebase 会将分支上的更改重新应用在目标分支上，重写提交历史。

rebase 方式提交的版本历史是线性的，不会创建新的合并提交，历史记录超级干净。

同样地，假设当前有两个分支，main 和 dev，用 rebase 方式合并分支的大致流程如下。

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

合并压缩

在rebase 的时候还可以使用 squash 参数来压缩提交记录，例如下图，Feature 1 分支的 A、B、C 三个提交记录，使用 rebase squash 后会在主分支变为一个提交记录 F。

使用方式如下，git rebase -i HEAD~3 命令准备压缩最近的3次提交，然后在编辑模式下将pick 改为 squash，最后推送到远端仓库。

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

选择使用哪种方法

具体使用哪种方式合并要根据场景和习惯而定，没有绝对的好坏。

使用 merge，如果你希望保留分支的历史记录，并且不介意有合并提交。适用于团队合作时保留每个人的工作记录。

使用 rebase，如果你希望保持提交历史的简洁和线性，适用于希望干净历史的项目。

有些公司规定只能用 rebase，它更适合那种只有单一版本的项目，只有一个主分支一直向前推进，且没有多个分支并行的情况，例如一个产品既要维护2.x 版本又要维护3.x版本，那用 rebase就不合适了。

之前 Vue 项目就是用 rebase 方式合并分支的。

本篇分享就到此结束啦！大家下篇见！拜~

点赞关注不迷路！分享了解小技术！走起！