如何在受限分支上確保BitBucket拉取請求No-FF策略的1個合並提交？

Question

我想始終對基分支沒有快進效果（始終創建合並提交）。 根據我的團隊使用的以下Bitbucket設置，似乎有時需要創建2個合並提交才能解決沖突。

Bitbucket服務器分支設置

• 沒有拉取請求的更改-防止將更改直接推送到指定分支； 僅在請求請求時才允許進行更改。 分行權限

• 合並提交 （--no-ff）始終創建一個新的合並提交並向其更新目標分支，即使源分支已經與目標分支保持最新。 默認合並策略

由於基本分支只能通過pull-requests進行更改，並且它始終在PR-merge上創建合並提交，因此，看來需要手動解決沖突的pull request必須進行2次提交。

問題場景示例：

這是場景：基本分支合並到功能分支上以手動解決沖突，在這種情況下，手動解決的沖突導致合並提交。 然后，在推送沖突合並提交之后，PR將被更新並准備好進行合並，並且在合並為基礎時，它將創建另一個合並提交（由於使用no-ff選項）。 從技術上講，僅需要這2個提交中的1個。 當直接在git中完成（沒有拉取請求並且沒有鎖定分支）時，可以使用no-ff通過直接合並到基礎分支來實現。

我在這里想念什么嗎？ 有沒有一種方法可以使用Bitbucket Server拉取請求限制來實現完全1個合並提交？

Answer 1

如果您已通過PR並使用no-ff合並策略將合並更改設置到基本分支中，則這是預期結果。

假設基本分支是master分支，並且pull請求用於將feature分支合並到master分支，並且提交歷史如下：

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

如果通過使用默認的合並策略將master分支合並到feature分支中來解決合並沖突，並在完成PR之后，則提交歷史將如下所示（commit G是第一個合並的提交，commit H是第二個合並的提交）：

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

為了使提交歷史清晰可見，您可以通過git cherry-pick或squash合並策略更改解決合並沖突的方法 。

• 如果將合並功能解析為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 merge的合並沖突：

   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