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

29 条回复 • 2024-11-29 09:27:44 +08:00

1

murmur

28 天前

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

2

RightHand

28 天前 via Android

当成 svn 来用呗

3

kera0a

28 天前 via iPhone

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

4

000sitereg

28 天前

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

5

Wxh16144

28 天前

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

6

malusama

28 天前

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

7

zsc8917zsc

28 天前

rebase 有代码覆盖的风险啊～

8

GeruzoniAnsasu

28 天前

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

9

donaldturinglee

28 天前

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

10

zealot0630

28 天前 via Android

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

11

jim9606

28 天前 via Android

1

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

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

12

wysnxzm

28 天前

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

13

virusdefender

28 天前

我一般 rebase master 之后再 merge

14

serco

28 天前

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

15

julyclyde

28 天前

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

16

julyclyde

28 天前

@zsc8917zsc 为什么会覆盖？

17

jybox

28 天前

2

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

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

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

18

wen20

28 天前

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

19

wen20

28 天前

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

20

yooomu

28 天前

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

21

Rache1

28 天前

如果只想保持 master 分支整洁的话，其实 merge 的时候加个 --squash 就好了。

22

newtype0092

28 天前

@wen20 和 rebase 比起来，merge 才更像拉屎，大家都可以方便的在空地来一坨，最后这个“雷区”会越来越大。
只能 rebase 是要求主分支迭代时严格的链式结构管理，说白了就是让并发开发的人通过额外的工作来保证 feature 被串行的 merge ，但对于其他读者，但串行的版本链肯定比并行的版本树清晰易懂的多。