rebase 还是 merge：一次团队协作后的反思

争论的两方

一派说「rebase 才有干净的历史」，一派说「merge 才保留真实过程」。两边都对，但都没说到点子上 —— 关键是你想让谁看懂这段历史。

我们最后定的规矩

• 个人分支同步主干：用 rebase，保持自己的提交线性
• 合并回主干：用 merge，且必须开 PR
• 主干：永远可发布，禁止直接 push

理由是：开发过程中的反复修改对 reviewer 没价值，但「这个功能什么时候进来的」对排查问题极有价值。

rebase 的雷

已经 push 到公共分支的提交，我是坚决不 rebase 的。原因很实际：

团队里只要有一个人的本地分支还被 force-push 影响过，接下来两小时就会有人在修冲突。

代价远大于收益。

一个实用命令

同步主干时我常用：

git fetch origin
git rebase origin/main

如果中途冲突，解决完 git rebase --continue。想放弃就 git rebase --abort，回到干净状态。

提交粒度

比策略更重要的一件事：一个提交只做一件事。

「修了 bug 顺便重构」这种提交，无论用 rebase 还是 merge 都是灾难。分裂成两个提交，git log 才有意义。

小结

工具没有对错，规矩才有。团队里定好一套、严格执行，比争哪种更优雅重要得多。