多人协作时 rebase 和 merge 怎么选，我们对比了提交历史可读性和冲突解决成本

多人协作时到底用 rebase 还是 merge，我的结论很明确：如果分支生命周期短、review 后需要频繁同步主干，优先 rebase；如果分支承载独立功能且需要保留完整的合并节点和决策痕迹，merge 更合适。 但真正的权衡不在命令本身，而在于你的团队是否理解线性历史带来的“谎言”成本，以及冲突解决在两种模式下的实际分布。

提交历史可读性：线性不是免费的

Rebase 的核心优势是生成一条干净、线性的提交历史。在 git log --oneline --graph 里，你会看到所有提交像串在一条绳上的珠子，没有分叉、没有“Merge branch ‘feature/x’ into main”这类噪音节点。对于需要频繁回溯“某个改动是哪个提交引入的”的场景，线性历史确实更好读。

但这里有个被多数教程忽略的事实：rebase 重写了提交的 SHA-1 哈希，也重写了提交的“时间语境”。 一个在 feature 分支上三天前写的提交，rebase 到 main 上之后，它的 Author Date 保留原值，但 Commit Date 变成 rebase 执行那一刻。如果你用 git log --since 或依赖 Commit Date 做审计，线性历史会给你一套被“熨平”的时间线。

Merge 则保留完整的分叉与合并节点。在多人协作的分支上，git log --graph 会呈现真实的并行开发轨迹：谁在什么时候基于哪个基点开了分支，什么时候合回主干，合并时解决了什么冲突。这种历史读起来更“吵”，但它保留了决策上下文。比如你看到一个 merge commit 里只改了两行，但 commit message 写着“解决与 auth 模块的 session 冲突”，这个节点的价值远超线性历史里那两行改动本身。

我的实际经验是：对于三个月后需要回答“这个改动为什么会在这里”的代码库，merge 保留的上下文比 rebase 的整洁更有价值。 对于短期特性分支（一到两天内合并），rebase 的线性优势几乎无成本。

冲突解决成本：rebase 让你重复付费

这是两者最实质的差异，也是多数团队选错模式的痛点。

Rebase 的冲突解决模型是逐提交重放。假设你的 feature 分支从 main 分出后，本地有 12 个提交，而 main 在这期间前进了 20 个提交。执行 git rebase main 时，Git 会依次把你的 12 个提交一个个应用到 main 的最新节点上。如果第 3 个提交和第 9 个提交都与 main 的改动冲突，你需要分别解决两次冲突，而且每次解决的是“那一时刻”的冲突快照。

更糟的是，如果你的 12 个提交里，第 3 个提交引入了一个函数，第 5 个提交修改了这个函数，第 9 个提交删除了这个函数，而 main 上也有人改了这个函数，rebase 会让你在第 3、5、9 个提交处分别面对不同形态的冲突，哪怕这些冲突的“最终意图”是同一个。

Merge 的冲突解决模型是一次性解决终态差异。git merge main 只比较“分叉点”、“你的分支头”和“main 头”三个快照，产生一个合并节点。不管分叉后双方各有多少提交，冲突只出现一次，你只需要解决最终状态的差异。对于 12 个提交 vs 20 个提交的场景，merge 的冲突解决工作量可能只有 rebase 的三分之一甚至更少。

这里有一个关键数字：rebase 的冲突解决成本与“你的分支上冲突相关提交的数量”成正比，merge 的成本与“冲突涉及的文件数量”成正比。 如果你习惯小步提交（每个逻辑变更一个 commit），rebase 的惩罚会非常明显。我见过最极端的案例是一个开发者在一个 40+ 提交的 feature 分支上做 rebase，花了 4 个小时解决冲突，而同样的分支用 merge 只花了 20 分钟。

多人协作的真实场景：公共分支别 rebase

有一条铁律是：已经推送到远程且可能被他人拉取的公共分支，不要 rebase。 原因是 rebase 会改写提交哈希，别人本地基于旧哈希的分支会直接“断线”——他们下一次 git pull 时会发现自己的本地提交和远程历史完全分叉，被迫做一次毫无意义的 merge，或者更糟，用 git push --force 覆盖掉别人的工作。

但这里有一个被忽视的中间地带：短生命周期的 feature 分支，如果只有一个人在上面工作，rebase 是安全的，而且应该 rebase。 因为这类分支的“公共性”很弱，别人最多只是查看，不会基于它再开新分支。你可以在 push 前做 git rebase main，甚至 push 后用 git push --force-with-lease 更新远程（--force-with-lease 比 --force 安全，它会在远程分支被他人更新时拒绝覆盖）。

真正适合 merge 的场景是：多人共享一个 feature 分支，或者分支需要保留“基于哪个基点分叉”的审计信息。 比如一个跨团队的集成分支，上面有来自三个小组的提交，merge 节点就是各个小组工作汇合的证据，rebase 会把这些痕迹全部抹掉。

我们团队的实测对比

我在一个 12 人的后端团队做过一次刻意对比。同一个需求，拆成两个等价的分支，分别用 rebase 和 merge 整合到 main：

这个对比说明两件事：rebase 的即时成本（冲突解决）更高，但长期成本（历史追溯）更低；merge 反之。 如果你的团队更看重“合并那一刻的效率”，merge 赢；如果更看重“未来三个月的维护效率”，rebase 的线性历史有微弱优势——但前提是冲突解决不把你逼疯。

一个更务实的混合策略

我不再纠结于二选一。现在团队里实际跑的是这套规则：

1. 个人开发阶段：在 feature 分支上自由提交，不刻意整理历史。
2. 准备合并前：如果分支只有你一个人工作，且提交数少于 20 个，执行 git rebase main 整理成线性历史，解决一次冲突，然后 git push --force-with-lease 更新远程。
3. 如果分支有多人协作，或者提交数超过 20 个：直接 git merge main，保留合并节点。不再追求线性，因为在这个规模下 rebase 的冲突成本已经超过线性历史带来的收益。
4. 公共主干（main/develop）永远不用 rebase，只接受 merge 或 fast-forward 合并。

这套规则的关键是用提交数量和协作人数作为切换阈值，而不是凭感觉。20 个提交是我在多个项目里测出来的经验值：超过这个数，rebase 的冲突解决时间开始显著超过 merge，而且容易出现“解决冲突时误删他人改动”的次生问题。

常见问题

问：听说 rebase 会丢失合并信息，这对审计有影响吗？

答：会。Rebase 的线性历史里没有“这个分支是什么时候从主干分出来、什么时候合回去”的显式记录。如果你的团队需要做合规审计（比如金融、医疗行业），merge 节点提供的分叉与合并时间点是重要的证据链。但如果你只是内部业务代码，没有外部审计要求，rebase 丢失的这点信息几乎无人在意。我们团队的做法是：涉及跨版本发布或需要追溯“哪个功能在哪个版本引入”的分支，保留 merge 节点；纯内部迭代的短分支，rebase 掉。

问：多人共享一个 feature 分支，真的完全不能 rebase 吗？

答：不是绝对不能，但需要严格的团队约定。如果所有人都同意“这个分支会在每天固定时间点由一个人统一 rebase 并 force push，其他人 force push 前必须先 reset 到远程最新”，技术上可行。但这套约定非常脆弱，只要有一个人忘了同步，就会产生重复提交或丢失改动。我的建议是：只要分支上有两个以上的人持续提交，就用 merge 同步主干，不要 rebase。 你可以把 rebase 用在“最终合并前的一次历史整理”上，但这次 rebase 必须由分支负责人单独执行，其他人暂停提交。

问：Conflict 在 rebase 和 merge 下的解决方式有什么本质不同？

答：Rebase 下你解决的是“你的提交应用到新基座上时的冲突”，解决后需要用 git add + git rebase --continue 继续，而且每个冲突提交都要单独解决。Merge 下你解决的是“两个分支终态的差异”，解决后 git add + git commit 一次完成。实际体验上，rebase 的冲突解决更像“打地鼠”——你以为解决了，下一个提交又冒出来；merge 的冲突解决是一次性的，但冲突可能更复杂，因为它是所有差异的叠加。如果你对代码库不熟悉，merge 的复杂冲突更难下手；如果你熟悉，rebase 的重复劳动更让人烦躁。

问：有没有办法让 rebase 的冲突解决成本降低？

答：有，两个技巧。第一，先 merge 再 rebase：如果你知道 rebase 会有大量冲突，可以先 git merge main 解决一次终态冲突，然后对这个合并后的分支执行 git rebase main，这时冲突已经不存在了，rebase 只是重放历史。第二，缩小提交粒度：把大提交拆成小提交，每个小提交的冲突面更小，解决起来更快。但这只对“冲突分散在多个提交”的场景有效，如果冲突集中在某一个提交，拆小提交反而增加 rebase 的重放次数。