如何确保在受限分支上为 BitBucket 拉取请求 No-FF 策略进行 1 次合并提交？

Question

我希望始终对基本分支没有快进效果（始终创建合并提交）。根据我的团队使用的以下 Bitbucket 设置，有时似乎需要创建 2 次合并提交才能解决冲突。

Bitbucket 服务器分支设置

• 没有拉取请求的更改 - 防止将更改直接推送到指定的分支；只有拉取请求才允许更改。 Branch Permissions

• Merge Commit (--no-ff) 始终创建一个新的合并提交并将目标分支更新到它，即使源分支已经与目标分支保持同步。 Default Merge Strategy

由于基础分支只能通过拉取请求进行更改，并且它总是在 PR-merge 上创建合并提交，因此看起来需要手动解决冲突的拉取请求必须有 2 次提交。

有问题的场景示例：

场景如下：基础分支被合并到功能分支以手动解决冲突，在这种情况下，手动解决的冲突导致合并提交。然后在推送冲突合并提交之后，PR 将被更新并准备合并，并且在合并到 base 后，它将创建另一个合并提交（由于 no-ff 选项）。从技术上讲，这 2 次提交中只需要 1 次。当直接在 git 中完成时（没有拉取请求并且没有锁定分支）这可以通过直接合并到基本分支上使用 no-ff 来实现。

我在这里遗漏了什么吗？有没有一种方法可以使用 Bitbucket Server 拉取请求限制来实现恰好 1 次合并提交？

Answer 1

如果您通过 PR 并使用 no-ff 合并策略将合并更改设置到基本分支，则这是预期结果。

假设基础分支是master分支，拉取请求是将feature分支合并到master分支，提交历史如下：

…---A---B---C---D     master
             \
              E---F  feature

如果你通过默认合并策略将 master 分支合并到 feature 分支来解决合并冲突，并且在完成 PR 后，提交历史将如下（提交 G 是第一个合并提交，提交 H 是第二个合并提交):

…---A---B---C-------D---H     master
             \       \ /
              E---F---G  feature

为了让提交历史看起来清晰，您可以改变解决合并冲突的方式git cherry-pick或压缩合并策略。

• 如果解决合并特性到master分支的合并冲突git cherry-pick:

  git checkout feature
  git cherry-pick D
  # resolve all conflicts
  git add .
  git cherry-pick --continue
  git push origin feature
  

  完成 PR 后，提交历史将是：

  …---A---B---C---D-------M     master
               \         /
                E---F---D'  feature
  

• 如果解决合并特性到master分支的合并与squash合并冲突：

  git checkout feature
  git merge master --squash
  # resolve all merge conflicts
  git add .
  git commit
  git push origin feature
  

  完成 PR 后，提交历史将是：

  …---A---B---C---D-------M2     master
               \         /
                E---F---M1  feature