rebase 和 merge 都能把一个分支的改动带到另一个分支，但它们对历史的态度完全不同。
一、merge：保留真实历史
merge 生成一个合并提交，两个分支的历史都原样保留，”谁在什么时候从哪合到哪”清清楚楚。代价是历史图会分叉交织，久了不易读。
二、rebase：重写成线性历史
rebase 把当前分支的提交”摘下来”，逐个重放到目标分支之后，得到一条直线。历史干净，但提交的哈希全部改变，等于改写了过去。
三、黄金法则
已经推送到远端、别人可能基于它开发的分支，不要 rebase。本地未推送的 feature 分支拉取主干更新时 rebase 最安全。
四、团队约定示例
- feature 分支开发期：频繁
git pull --rebase保持干净。 - 合并进主干：走 merge（或平台上的 squash merge），保留可追溯的合并点。
- 个人分支整理：交互式 rebase 压缩、拆分、修改提交。
五、出事怎么办
rebase 中断后 git rebase --abort 可以全身而退；已经搞砸了，git reflog 里几乎总能找回 rebase 之前的 HEAD。
