所以我有一个master分支和一个development分支；它们都被锁定，因此只能通过拉取请求来更改分支。我想将开发中的一些更改合并到服务器上的master中，并创建了一个pull请求来做到这一点。但是存在冲突，因此我在本地手动进行了合并，并尝试将更改推送到服务器。由于要求提取请求的政策，我无法执行此操作！还有其他方法可以解决冲突而不违反政策吗？我现在能想到的就是放弃拉取请求并创建一个新请求，但是我不确定这是否还能满足我的需要-如果没有本地解决方案，就无法真正解决我所知道的冲突合并，并且没有办法将解决的更改带到我知道的master分支中，而没有推送到master分支，这是政策禁止的-帮助吗？
答案 0 :(得分：0)
创建针对开发的PR时会引发冲突，对吗？我想您能做的最好的事情就是将其转换为合并到开发之上的单个修订版（如果可能的话）...然后您可以从中创建PR。
所以.....您已经与develop合并，对吧？
POST /me/drive/items/{itemId}/createLink
Content-type: application/json
{
"type": "view",
"scope": "anonymous",
"password": "itsasecret"
}
现在，解决所有冲突之后的所有更改都将在开发后（开发未移动）的单个修订版中进行。推动该分支（这将自行更新PR，并允许您合并）。
答案 1 :(得分：0)
如果我了解您的设置，那么您应该通过 PR 从功能/特性分支更改为 develop ，对吗？然后，您可以使用另一个 PR 将更改从 develop 更改为 master （按照惯例，因为分支策略未定义特定分支之间的关系）。
放弃当前的 PR ，因为它没有强制作用而破裂。根据当前的开发创建一个新的功能/冲突解决方案分支。然后在本地主机上拉最新的 master ，它们合并 master => 功能/冲突解决方案。这应该给您带来与开发者和母版之间在 PR 中看到的相同冲突。解决这些冲突，并推送到远程 feature / ConflictResolution ，以启动新的PR进行开发，然后转变为母版。
这与上一个选项基本相同，除了要在 conflictResolution 分支和 master 之间创建PR。我认为这将删除您在 develop 和 master 之间需要对PR进行的任何更改，因此，在您告诉它重新合并后，现有PR可能会“消失”。
您仍然想使用基于主干的策略，这很好，但是请不要使用锁定的developer分支约定。将策略保留在master上，确保它是必需的，在其上添加一个构建验证，并将其命名为好。这将迫使进入主服务器的所有更改都使用PR并执行还原>>构建>>测试门构建。如果您有严格的部署创作过程，请使用标签来标记历史上的那些仪式里程碑。
这是good video，涉及一些策略以及它们如何逐渐成熟并赢得信任。
答案 2 :(得分：0)
昨晚我与老板讨论了这个问题，他想出了办法：
1）既掌握又发展了
2）从母版合并到本地开发
3）解决了冲突
4）创建并完成拉取请求
5）拉动发展
答案 3 :(得分：0)
正确的过程是，您应该将 master 分支合并到您的 development 分支，然后将更改提交并推送到 development 分支，然后创建提取请求以将更改合并到 Master 。
有些扩展程序可以在线解决冲突，而无需在本地进行。