冲突的产生是因为两个不同的分支都修改了同一个文件。如果“staging”上的“only”提交是从“develop”合并的，就不会有任何冲突。
一对长期分支发生冲突有两个常见的原因（这里我将使用“开发”和“登台”的例子;这同样适用于“分级”和“主”）。
1.在“staging”分支上有一些不是在“develop”分支上的更改。有时候，你可能需要在测试“staging”分支时修复一些东西，所以你直接将其合并到“staging”分支。在某些时候，这些更改也需要进入“develop”分支--否则每次有人在那里测试时它都会被破坏。为了让git知道它在两个分支上都存在，这需要从“登台”到“开发”的“合并”，而不仅仅是应用相同的更改。
1.你使用了错误的合并类型。如果你使用了“squash merge”，git * 会完全忽略被合并分支的历史记录 *，并创建一个包含所有修改的提交。有些人喜欢这样做来保持他们的历史记录“整洁”，但是你不应该把压缩合并和你要继续使用的分支一起使用.因为压缩提交不t引用另一个分支的历史记录，*git不知道那些修改已经在两个分支上 *，所以当你再次合并时，它会尝试再次应用它们。
这两种情况下的解决方案是相同的：
1.合并所有从“staging”到“develop”的更改，并解决其中的冲突。每当你对“staging”做了一个不是来自“develop”的更改时，重复这个步骤。
1.请确保您对该合并以及将来在“开发”和“登台”之间的所有合并使用“真正合并”/“合并提交”。

1.有矛盾是正常状态吗
1.对于合并，您需要解决冲突，否则可能会丢失使用直接推送所做的更改。
1.对于功能分支开发，需要解决冲突
1.对于开发-〉试运行-〉主团队，需要审查变更并解决冲突