Question

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

Bitbucket服务器分支设置

没有拉取请求的更改-防止将更改直接推送到指定的分支；仅在请求请求时才允许进行更改。 Branch Permissions
合并提交（--no-ff）始终创建一个新的合并提交并向其更新目标分支，即使源分支已经与目标分支保持最新。 Default Merge Strategy

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

问题场景示例：

这里是场景：基本分支合并到功能分支上以手动解决冲突，在这种情况下，手动解决的冲突导致合并提交。然后，在推送冲突合并提交之后，PR将被更新并准备好进行合并，并且在合并为基础时，它将创建另一个合并提交（由于使用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之后，则提交历史将如下所示（commit G是第一个合并的提交和提交H是第二个合并的提交）：

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

为了使提交历史清晰可见，您可以更改通过git cherry-pick或通过合并策略解决合并冲突的方式。

如果将合并功能解析为与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

如果将合并功能解决为主分支与壁球合并的合并冲突：

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

如何在受限分支上确保针对BitBucket拉取请求No-FF策略的1个合并提交？

问题场景示例：

1 个答案: