2026 年 5 月 12 日 · 工程实践
Git 工作流：Rebase 与 Merge 的正确打开方式
团队协作中 rebase 和 merge 到底怎么选？本文从提交历史的角度梳理两种方式的区别与适用场景，并给出可落地的分支策略。
Git 团队协作
在多人协作的项目里，git merge 与 git rebase 是出现频率最高的两个操作。很多人凭习惯选择，却说不清两者的区别。
Merge：保留真实的合并历史
merge 会创建一个新的合并提交，把两个分支的历史"缝合"在一起。它的优点是完整保留了"什么时候、把哪个分支合进来"的真实记录，非常适合记录 feature 合入主干这样的里程碑事件。
Rebase：让历史保持线性
rebase 会把当前分支的提交"重放"到目标分支的最新提交之上，得到一条干净、线性的历史。这在 review 时非常友好，因为每条提交都一目了然。
推荐的团队约定
- 拉取远端更新用
git pull --rebase，避免产生无意义的合并提交； - feature 分支合入主干用
merge --no-ff，保留功能边界； - 绝不对已经推送到共享远端的提交执行 rebase，否则会重写他人的历史。
核心原则只有一条：公共历史不重写，私有历史随便改。