这篇文章档用于说明在多人协作开发中。如何正确使用 git rebase 保持提交历史清晰、减少无意义的 merge commit，并降低多人并行开发时的集成成本。

这篇文章特别适用于如下协作模式：

• master 作为主干分支
• 某个完整需求从 master 拉出功能总分支，例如 feature/
• 每位开发人员从 feature/ 拉出个人开发分支，例如 feature/-zhangsan
• 每个阶段开发完成后先整理个人提交。再将个人分支无额外 merge commit 地合回功能总分支

从主要原则来看，避免常见痛点

. rebase 重放的是“当前分支”的提交

git checkout feature/-zhangsangit
git rebase feature/

痛点：很多人误以为会把目标分支所有提交搬到当前分支后面从而导致大量冲突和不可预期的结果。

• 以 feature/ 最新提交为基底；
• 把 自己独有的提交重放到此基底之后。

. 想让谁接到别人后面就先 checkout 谁

痛点：切换错误分支往往导致不必要的冲突解决工作量翻倍。

. 仅在个人分支上使用 rebase

. 目标是线性历史，而不是制造“整洁但危险”的历史

什么时候应该用 Git Rebase？——消除多余 Merge 的痛点场景

• 个人开发分支需要同步功能总分支最新代码；
• 准备合回功能总分支前整理提交历史；
• 想避免产生额外 merge commit；
• 想让最终提交链保持线性、易读。

不建议：

• 公共分支已被多人基于其继续开发；
• 团队成员不熟悉冲突处理流程；
• 已推送且被他人依赖的历史

推荐工作流——一步步消除混乱与冲突累积风险

. 从 master 拉出功能总分支：

git checkout master
git pull
git checkout -b feature/

. 每位开发人员从功能总分支拉出自己的开发分支：

git checkout feature/
git pull
git checkout -b feature/-zhangsan

. 在个人开发分支上进行多次临时提交：

git commit -m "wip: 完成第一部分"
git commit -m "fix: 修正样式"
git commit -m "update: 补充接口逻辑"

. 一阶段完成后先整理提交：

git rebase -i HEAD~N # N 为本阶段临时提交数