在Bitbucket Server中使用分支权限时解决具有合并冲突的拉取请求

3bh*_*3bh 6 bitbucket-server

我们已经开始在我们的团队中使用Bitbucket Server,并且希望强制使用pull请求来从功能分支到我们的主要集成分支.为了强制执行此操作,我们启用了分支权限功能,该功能可防止合并而无需对这些分支执行拉取请求.这很有效,直到我们得到一个有冲突的pull请求.

在这种情况下,指令说要手动获取源分支的头部并将其合并到目标,然后将其推送.但是,合并提交被分支权限拒绝!

我们在这里遗漏了什么,或者在使用分支权限时是否无法手动合并?

Aav*_*dav 9

在BitBucket服务器上,当我们在合并任何拉取请求时遇到任何冲突时,我们可以使用git bash工具在我们的本地系统上解析它,然后我们可以提交并将我们的更改推送到远程功能分支并将其合并到主分支.

在我们的本地系统的git bash工具中,需要遵循以下步骤.

(1)打开git bash工具并结帐或切换到本地功能分支.

(2)将最新的更改从主分支(比如'master')拉入功能分支.

git pull origin master
Run Code Online (Sandbox Code Playgroud)

(3)如果上述命令由于某些本地更改而失败,则使用以下命令存储它们,否则转到下一步.

git stash
Run Code Online (Sandbox Code Playgroud)

其次是 -

git pull origin master
Run Code Online (Sandbox Code Playgroud)

(4)如果发生冲突,自动合并将失败,因此我们需要手动合并.使用以下命令解决冲突.

git mergetool
Run Code Online (Sandbox Code Playgroud)

默认情况下,它将显示所有可用的合并工具,其中一个将自动选中.如果我们觉得我们对任何其他工具感到满意,那么我们也可以配置它,git将为我们打开该工具以解决冲突.

(5)解决冲突后,将更改提交到功能分支.

git commit
Run Code Online (Sandbox Code Playgroud)

(6)将更改推送到远程功能分支.

git push
Run Code Online (Sandbox Code Playgroud)

在BitBucket服务器上验证,现在pull请求应该自动更新.

再次尝试合并它; 如果没有冲突,它将成功合并.

如果它再次发生合并冲突(如果有人在我们解决本地系统冲突期间在主分支中提交了新的更改),请再次按照上述步骤解决它们.

如果我们按顺序执行上述步骤,我们应该能够成功解决任何冲突.

谢谢,希望它有所帮助.


Dav*_*ley 6

当我们进入肮脏的自动合并场景时,无论是通过分支权限还是通过自动合并冲突,使用功能/错误修复分支,我们都会执行以下操作:

在存储库的本地克隆中:

  1. 使用“git checkout [目标分支]”签出目标分支。
  2. 使用“git pull origin [远程目标分支]”使用远程的最新更改更新主分支。
  3. 使用“git checkout -b feature/[我的分支描述]”签出新功能分支
  4. 使用“git fetch origin [源分支]”从源分支获取最新更改。
  5. 使用“git merge FETCH_HEAD”将获取的更改合并到目标分支中。我们使用“git fetch”而不是“git pull”来避免首先检查源分支并更新它。因此,“git merge [源分支]”和“git merge FETCH_HEAD”(在“git fetch origin [源分支]”之后)之间的区别在于,后者将合并远程上该分支的状态,而前者则合并远程分支的状态。该分支的本地状态(可能不同,甚至可能不存在)。
  6. 现在解决冲突。
  7. 使用“git add”或“git stage”暂存更改的文件。
  8. 使用“git commit -m [您的提交消息]”将更改提交到功能分支。
  9. 使用“git Push origin feature/[我的分支描述]”将更改推送到远程。
  10. 使用响应消息中提供的 URL 在 Bitbucket 中启动新的拉取请求。确保选择正确的目标分支。如果可能,应允许继续自动合并。
  11. 既然您已经创建了新的拉取请求,请拒绝原始拉取请求。确保在您缺席的情况下不会自动将其他提交添加到原始 PR 中。

这是 CLI 上的:

git checkout <destination branch>
git pull origin <destination branch on remote>
git checkout -b feature/<my branch description>
git fetch origin <source branch>
git merge FETCH_HEAD
<fix conflicts>
git stage <changed files>
git commit -m <my message>
git push origin feature/<my branch description>
<continue in bitbucket>
Run Code Online (Sandbox Code Playgroud)


Rog*_*Rog 5

不幸的是,这些说明与某些权限组合有点不一致,我们希望有一天能修复这个问题(我在 Bitbucket 上工作)。

要解决此问题,您可以通过合并目标分支中的更改来解决源分支上的冲突。

  • 看起来好像没有修好。我在其他地方看到“通用说明”在大多数情况下都有效,但这似乎很奇怪。如果我正在处理更改并与目标分支产生合并冲突,为什么典型用例是更新目标分支而不是源分支?PR 的重点是审查源更改以使它们达到目标,而不是相反。 (4认同)