rebase vs merge 选择
rebase 和 merge 是 Git 合并分支的两种策略，各有适用场景。
历史结构对比
Bash
merge 产生的历史：
A → B → C → M（合并提交）
↗
D → E
rebase 产生的历史：
A → B → C → D' → E'
（线性历史，无合并提交）
特点对比
| 特性 | merge | rebase |
|---|---|---|
| 历史 | 分叉，真实记录 | 线性，干净整洁 |
| 合并提交 | 有 | 无 |
| 提交顺序 | 按时间 | 按变基顺序 |
| 回溯能力 | 容易追溯分支 | 分支信息丢失 |
| 安全性 | 安全，不改历史 | 改写历史，需谨慎 |
使用场景选择
选择 merge
| 场景 | 原因 |
|---|---|
| 合入公共分支 | 保持历史真实 |
| 已推送的分支 | rebase 会改写历史 |
| 团队协作分支 | 保留协作信息 |
| 重要功能分支 | 追溯功能来源 |
选择 rebase
| 场景 | 原因 |
|---|---|
| 本地开发分支 | 清理本地历史 |
| 功能分支更新 | 同步上游变更 |
| 提交整理 | 合并、编辑提交 |
| 保持历史整洁 | 线性历史易读 |
最佳实践
功能分支开发流程
Bash
# 定期同步上游（用 rebase）
git checkout feature
git fetch origin
git rebase origin/main
# 完成后合入（用 merge --no-ff）
git checkout main
git merge --no-ff feature
本地提交整理
Bash
# 整理本地提交历史
git rebase -i HEAD~3
# 推送前确保历史整洁
git push origin feature
避免的操作
text
# 错误：对已推送分支 rebase
git push origin feature
git rebase main
git push origin feature # 会冲突！
# 正确：已推送分支用 merge
git merge origin/main
团队协作建议
| 分支类型 | 合入方式 |
|---|---|
| 功能分支 → main | merge --no-ff |
| 本地分支同步上游 | rebase |
| 已推送分支更新 | merge |
| 提交整理 | rebase -i |
决策原则
- 已推送用 merge：不改写远程历史
- 本地用 rebase：保持历史整洁
- 合入公共分支用 merge：保留历史信息
- 整理提交用 rebase -i：合并、修改提交
选择原则：本地整理用 rebase，团队协作用 merge。
要点总结
- merge 保留真实历史，rebase 使历史线性
- 已推送分支只能用 merge
- 本地分支可以用 rebase 整理
- 合入公共分支推荐 merge --no-ff
- 功能分支同步上游可用 rebase
📝 发现内容有误？点击此处直接编辑