目前，我们有以下分支:
Develop: Internal masterStaging:客户评审Master: Production
流量为featureBranch -> Develop -> Staging -> Master
我希望不允许直接推送到这些分支中的任何一个，而只能通过拉请求。
由于我们很少推送到staging,master分支，我们一直从develop分支创建分支。
，因此在创建PR之前，我们从develop拉到featureBranch。
现在，当将develop合并到staging或staging合并到master时，我们有冲突。我不想直接推送到这些分支，而只想通过拉取请求。
我做错了什么?如何解决这个问题?
由于两个不同的分支都更改了同一个文件，因此会产生冲突。如果只有提交了"staging"从"开发"中合并，不会有任何冲突。
一对长寿命分支发生冲突有两个常见原因(我将使用"develop"的例子)。和";staging"在这里;这同样适用于"分期付款"。和"master")
- "staging"这些都没有"发展"。有时，您可能需要在测试"分段"时修复某些东西。分支，所以你直接将它合并到"staging"分支。在某种程度上，这种变化需要得到"发展"。也一样——否则每次有人在那里测试它都会被破坏。要让git知道它在两个平台上都存在，就需要使用mergefrom "staging"要"发展"，而不是仅仅应用相同的更改。
- 您使用错误的合并类型。如果你使用"squash merge"，git会完全忽略被合并分支的历史记录，并创建一个包含其所有更改的单一提交。有些人喜欢这样做，以保持他们的历史"整洁"，但是你不应该在你打算继续使用的分支中使用一个压缩合并。． 因为被压缩的提交不引用其他分支的历史记录，git不知道这些更改已经在两个分支上了，所以当你再次合并时，它会尝试再次应用它们。
这两种情况的解决方案是相同的:
- 合并所有从"staging"发展"，解决矛盾。每当您更改"分段"时，请重复此操作。而不是来自"发展"。
- 请确保使用"true"/"合并提交"对于这次合并，以及未来所有在"发展"之间的合并;和"staging">
-
有冲突是正常状态吗
-
对于合并，您需要解决冲突，否则您可能会丢失使用直接推送的更改。
-
功能分支开发需要解决冲突
-
For develop ->分段→主团队需要审查变更并解决冲突