`Rebase and merge` 合并策略在 Bitbucket Server 上有什么作用？答案

【问题标题】：What does the `Rebase and merge` merge strategy do on Bitbucket Server?`Rebase and merge` 合并策略在 Bitbucket Server 上有什么作用？
【发布时间】：2019-06-25 00:23:45
【问题描述】：

我正在探索 Bitbucket Server 上可能的合并策略，其中一个策略引起了我的注意：“Rebase and merge”rebase + merge --no-ff

我知道大多数关于合并策略的争论都围绕着 rebase vs 合并。这种合并策略似乎是 rebase 和合并。它是否正确？与仅 rebase 或仅合并相比，这会带来什么优势？

【问题讨论】：

标签： git-rebase bitbucket-server fast-forward

【解决方案1】：

“变基和合并”策略通常是人们所说的“变基”。它也只是表明接下来会发生什么。当您使用--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

【讨论】：

所以使用--no-ff 进行rebase 可以让我拥有（某种程度上）更清晰的历史记录，而不会丢失分支提供的可追溯性？我一直将“变基”策略理解为您的最后一个示例。这清除了事情
您已经正确理解了。我很高兴能帮上忙。 :)

【解决方案2】：

Bitbucket 服务器文档对 Rebase、merge (rebase + merge --no-ff) AND Rebase、fast-forward (rebase + merge --ff-only) 合并策略进行了说明。

“本次操作未修改PR分支”

根据此语句，在您的示例中，分支 B 中提交的 commitSHA 将保持不变。当应用于分支 A 时，Bitbucket 将为相同的提交分配新的 commitSHA。

【讨论】：