对于不允许 merge 只允许 rebase 的开源项目，各位怎么看？这是一个好习惯吗？

[villivateur]

比如 https://github.com/ArduPilot/ardupilot 这个项目，明确规定只允许 rebase 不许 merge 。

这是一个好习惯吗？

[murmur]

rebase 做出来的树一条直线，贼 tm 漂亮，我以前做过有的项目就是用 rebase

[RightHand]

当成 svn 来用呗

[kera0a]

无所谓吧，merge 和 rebase 合并其实没本质上的区别

[000sitereg]

我是能 rebase 就不 merge 。rebase 的时候有冲突就处理。从常理理解，别人先提交，log 中就在我之前，一条直线很好理解。

[Wxh16144]

无所谓 +1, 两个都做到会用，严于律己即可，别人如何规定就遵循他的规则罢了

[malusama]

没什么差别啊， 而且 rebase 漂亮多了

[zsc8917zsc]

rebase 有代码覆盖的风险啊～

[GeruzoniAnsasu]

这么说，rebase 之于 merge 约等于 golang 之于 c++

[donaldturinglee]

merge 的话用 git log graph 有时候脑一抽不容易看得清楚...

[zealot0630]

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

[jim9606]

一般用 rebase,用不了的时候采用 merge 。不能用 rebase 的原因有:
1. 分支不是私有的，已经被多人 checkout 或者 branch,rebase 会对合作者的工作流造成破坏
2. 需要保留原始提交的时间轨迹，例如分支发布过版本
3. commit 带 gpg 签名，rebase 毫无疑问会破坏签名
4. 分支差异过大，rebase 过程会大量 conflict

svn 和 git 的根本性区别是集中式 vs 分布式，只是因为 git 的 branch 成本低所以能玩得转频繁分支的工作流

[wysnxzm]

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

[virusdefender]

我一般 rebase master 之后再 merge

[serco]

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

[julyclyde]

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

[julyclyde]

@zsc8917zsc 为什么会覆盖？

[jybox]

准确地说是只允许 fast forward 的 merge ，即需要合并的分支基于目标分支的最新版本，如果不是的话就需要 rebase 到最新版本再 merge 。

除了历史看着「干净」之外，我觉得最大的好处是在 rebase 之后、merge 之前，你还有机会检查你的代码、运行测试（其他人也可以在 PR 上继续 review 、CI 也会重新运行）。而在 GitHub 上直接点 merge 的话改动就直接被合并到目标分支，没有就会再检查了（当然你可以在本地 merge 并检查）。

很多时候即使 merge 没有冲突，代码也可能会跑不起来。

[wen20]

https://jhall.io/archive/2024/01/11/when-i-dont-rebase/
这篇说的最好，
总结一句话：rebase 只用在自己本地分支。

[wen20]

公共分支 rebase 如同沙滩拉屎，个人很方便， 然而别的伙伴需要避免踩屎。

[yooomu]

通常 feat branch 会使用 rebase ，但是往 master 合并代码时使用 merge ，这样链路非常清晰