我正在探索 Bitbucket Server 上可能的合并策略,其中一个策略引起了我的注意:“变基和合并”rebase + merge --no-ff
我知道大多数关于合并策略的辩论都围绕着变基与合并。这种合并策略似乎是变基和合并。这个对吗?与仅变基或仅合并相比,这会带来什么优势?
我正在探索 Bitbucket Server 上可能的合并策略,其中一个策略引起了我的注意:“变基和合并”rebase + merge --no-ff
我知道大多数关于合并策略的辩论都围绕着变基与合并。这种合并策略似乎是变基和合并。这个对吗?与仅变基或仅合并相比,这会带来什么优势?
“变基和合并”策略通常是人们所说的“变基”。它也只是表明接下来会发生什么。当您使用--no-ff
时,它会进行合并提交。没有它,你会得到一个快进,所以两个 refs 都指向同一个提交,它隐藏了你已经分支的事实。
合并B
到A
:
A *---* A *---*---*
\ merge -> \ /
B *---* B *---*
重新定位B
到A
:
A *---* A *---*
\ rebase -> \
B *---* B *---*
变基并合并 ( --no-ff
)B
到A
:
A *---* A *---* A *---*-------*
\ rebase -> \ merge -> \ /
B *---* B *---* --no-ff B *---*
变基并合并 ( --ff
)B
到A
:
A *---* A *---* A,B *---*---*---*
\ rebase -> \ merge ->
B *---* B *---* --ff
Bitbucket Server 文档对 Rebase、merge (rebase + merge --no-ff) AND Rebase、fast-forward (rebase + merge --ff-only) 合并策略进行了说明。
“此操作未修改 PR 分支”
根据此语句,在您的示例中,分支 B 中提交的 commitSHA 将保持不变。当应用于分支 A 时,Bitbucket 将为相同的提交分配新的 commitSHA。