rebase 还是 merge：一条可执行的判断标准
示例文章，用于演示分页与列表排版，请替换成你自己的内容。
关于这两个命令的争论经常停留在审美层面，其实有一条更实用的判断标准。
历史属于谁
判断的关键是：这段历史有没有别人基于它工作过。
- 分支还没推上去、或者只有你自己在用 → 可以 rebase，随便改
- 分支已经推上去了、别人可能拉过 → 不要 rebase
rebase 会重写提交，产生新的 SHA。别人基于旧提交做的工作会失去共同祖先，拉取时要么冲突一片，要么把重复提交带回来。这才是 rebase 真正的问题，跟「历史好不好看」无关。
各自的代价
| merge | rebase | |
|---|---|---|
| 历史 | 保留分叉，有合并提交 | 线性 |
| 冲突 | 一次性解决 | 可能每个提交都要解 |
| 改写提交 | 不会 | 会 |
| 定位问题时 | 能看出功能是整体合入的 | 提交像是一条条直接写在主干上 |
rebase 的冲突更麻烦：它逐个提交重放，同一个冲突可能在多个提交上反复出现。merge 只在合并那一刻解一次。
一个够用的工作流
- 本地分支上随便 rebase，把历史整理干净
- 推上去之后就不再 rebase
- 合入主干用 merge
- 主干需要同步到分支时，在分支上 merge 主干，不要 rebase 分支
最后一条常被忽略：很多人为了保持分支「干净」去 rebase 主干，结果把自己分支上已经推出去的提交全部重写了。