rebase 还是 merge，我把团队的分歧整理成了三条规则

我们组两个人，为 Git 的用法吵了一下午。我习惯在 feature 分支上定期 rebase 主干，保持提交线是一条直线；同事坚持 merge，理由是"历史就是历史，不该改写"。谁也说服不了谁，因为两个人说的都对。

后来把争论焦点拆开看，其实只有一个问题：已推送的提交能不能重写。rebase 的本质是把你的提交摘下来，重新安到新的基底上——提交内容没变，但身份（hash）全变了。如果这些提交已经推到远端、别人可能已经基于它们开发，重写就是灾难；如果只有你自己在用，重写反而让历史干净。

所以最后定下来三条规则，挂在了 README 里：

• 自己的 feature 分支，随时 rebase 主干，推送前整理提交（squash 掉那些 fix typo）
• 合入主干的动作统一用 merge --no-ff，保留"这一批做了什么"的批次感
• 主分支上的提交，永远不改写

一句话版本：rebase 用在自己的分支上，merge 用在别人看得见的地方。

执行几个月下来，偶尔还是有新人问"为什么我 pull 下来又多了一个 merge commit"。十次有九次是 git pull 没带 --rebase。把全局配置 pull.rebase true 打开之后，这类问题就绝迹了。

规则不是真理，是让团队少吵架的约定。哪天换成十人团队，这三条大概率要重写——那也正常。