Git Merge vs Rebase | Vibe Learning

Git Merge vs Rebase

核心对比 #

维度	Merge	Rebase
历史记录	保留真实分支历史	改写成线性历史
提交 ID	不变	全部改变
合并提交	产生 merge commit	无额外提交
可视化	分支图像树杈	一条直线
安全性	高（不改写历史）	低（改写历史）

工作原理对比 #

操作前	Merge 结果	Rebase 结果
`main: A→B→C` `feature: A→D→E`	`A→B→C→M` `└→D→E→┘`	`A→B→C→D'→E'`
两个分支	保留分支痕迹	看起来从未分支

提交 ID 变化 #

属性	原始提交 C	Rebase 后 C'
提交 ID	abc123	def456
代码内容	你的改动	你的改动（相同）
父提交	B	main 最新提交
时间戳	10:00	15:00（rebase 时间）

使用场景对比 #

场景	推荐操作	原因
公共分支合并	Merge	保留协作历史
已推送的分支	Merge	避免破坏他人工作
本地分支整理	Rebase	保持历史整洁
更新 feature 分支	Rebase	避免无意义的合并提交
热修复合并	Merge	需要追踪修复时间点
实验性功能	Rebase	整理后再合并

优缺点对比 #

方面	Merge	Rebase
优点	• 安全 • 保留完整历史 • 冲突处理简单 • 容易撤销	• 历史整洁 • 便于代码审查 • 利于 bisect 查错 • 无合并提交
缺点	• 历史混乱 • 大量合并提交 • 分支图复杂	• 改写历史危险 • 失去时间线 • 冲突需逐个解决 • 协作困难

冲突处理对比 #

维度	Merge	Rebase
冲突次数	1 次	N 次（每个提交）
解决方式	在合并提交中一次解决	逐个提交解决
放弃操作	`git merge --abort`	`git rebase --abort`
继续操作	`git commit`	`git rebase --continue`

命令对比 #

操作	Merge	Rebase
基础命令	`git merge feature`	`git rebase main`
拉取更新	`git pull`	`git pull --rebase`
交互模式	无	`git rebase -i`
撤销操作	`git revert -m 1 <commit>`	`git reflog` + `git reset`

风险等级 #

操作	风险等级	说明
`git merge main`	⭐ 低	只是合并，不改历史
`git rebase main`（本地）	⭐⭐ 中	改写本地历史
`git rebase main`（已推送）	⭐⭐⭐⭐⭐ 极高	破坏团队协作
`git push --force`	⭐⭐⭐⭐⭐ 极高	覆盖远程历史

黄金法则 #

规则	说明	后果
不 rebase 公共分支	main、develop 等	团队历史混乱
不 rebase 已推送代码	已 push 的提交	同事无法同步
不在 main 上 rebase	`git checkout main && git rebase`	主分支历史被改写

最佳实践 #

阶段	推荐操作	命令
本地开发	Rebase 保持更新	`git pull --rebase origin main`
推送前	整理提交历史	`git rebase -i HEAD~3`
合并功能	Merge 到主分支	`git merge --no-ff feature`
热修复	Cherry-pick 或 Merge	`git cherry-pick <commit>`

选择决策树 #

问题	是 →	否 →
代码已推送？	用 Merge	继续判断
是公共分支？	用 Merge	继续判断
需要保留完整历史？	用 Merge	继续判断
想要整洁历史？	用 Rebase	用 Merge

总结 #

Merge：真实但混乱，适合公共协作
Rebase：整洁但危险，适合本地整理

记住：公共用 Merge，本地用 Rebase。