当你需要 bisect 时候，就知道好处了

一般用 rebase,用不了的时候采用 merge 。不能用 rebase 的原因有: 1. 分支不是私有的，已经被多人 checkout 或者 branch,rebase 会对合作者的工作流造成破坏 2. 需要保留原始提交的时间轨迹，例如分支发布过版本 3. commit 带 gpg 签名，rebase 毫无疑问会破坏签名 4. 分支差异过大，rebase 过程会大量 conflict svn 和 git 的根本性区别是集中式 vs 分布式，只是因为 git 的 branch 成本低所以能玩得转频繁分支的工作流

回滚找不到节点的时候就老实了

我一般 rebase master 之后再 merge

从前也是 rebase ，后面遇到几次莫名代码丢了就不这么干了

@kera0a 最终内容没区别，但是实施代价的区别极大

@zsc8917zsc 为什么会覆盖？

准确地说是只允许 fast forward 的 merge ，即需要合并的分支基于目标分支的最新版本，如果不是的话就需要 rebase 到最新版本再 merge 。 除了历史看着「干净」之外，我觉得最大的好处是在 rebase 之后、merge 之前，你还有机会检查你的代码、运行测试（其他人也可以在 PR 上继续 review 、CI 也会重新运行）。而在 GitHub 上直接点 merge 的话改动就直接被合并到目标分支，没有就会再检查了（当然你可以在本地 merge 并检查）。 很多时候即使 merge 没有冲突，代码也可能会跑不起来。