TFS合并冲突
我有主分支和开发分支。我对两者进行更改并签入。我从 main 合并到 dev 并签入。现在我从 dev 合并到 main。我有冲突。这怎么可能？
I have main and dev branches. I make changes in both and check in. I merge from main to dev and check in. Now I merge from dev to main. I have conflicts. How is this possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
解决一个方向上的合并冲突不一定适合另一方向上的合并。在许多工作流程中，您基本上会进行合并，以便使两个分支尽可能相似 - 例如，将更改从开发分支转移到生产分支，并且可能将关键错误修复从生产分支移回开发分支。在这种工作流程中，您通常不希望在合并两个分支时出现分歧（毕竟，您希望在两个分支中都修复关键错误），因此为什么必须两次解决合并冲突并不明显，但这肯定是不是使用分支机构时的唯一工作流程。
我曾经参与过一个 Java 项目，该项目有一些实用程序库，我们与从事不同项目的小组共享这些实用程序库。在某些时候，我们的库由于各种原因需要与他们的库有所不同，因此我们采用了他们项目的一个分支，两个团队都对库进行了独特的更改。有时我们会修复一个错误，有时他们会添加一个新功能，所以我们经常相互合并。
这里你可以看到，从我们的分支合并到他们的分支的结果并不一定是从他们的分支合并到我们的分支的结果。假设有一个文件，我们在其中添加了一些新方法，并且可能修复了一些错误。我们假设他们添加了一些不同的方法。当他们将我们的更改合并到他们的分支时，他们会遇到合并冲突，我们假设他们接受了错误修复，但没有接受我们的新方法，因为他们不需要它们。现在，当我们进行合并以将他们的更改放入我们的分支时，我们仍然会遇到合并冲突 - 这允许我们将他们的方法放入我们的文件中。
如果 TFS 根据我们分支到他们分支的结果对从他们分支到我们分支的合并做出一些假设，那将是不准确的。
Resolving a conflict for a merge in one direction is not necessarily appropriate for a merge in another direction. In many workflows you're basically merging in order to keep two branches as similar as possible - for example, taking changes from a development branch into a production branch, and maybe moving critical bugfixes from the production branch back to a development branch. In this sort of workflow, you typically wouldn't want to diverge when merging two branches (you want that critical bugfix in both branches, after all) so it's not obvious why you would have to resolve the merge conflict both times, but that's certainly not the only workflow when working with branches.
I used to work on a Java project that had some utility libraries that we shared with a group working on a different project. At some point, our libraries needed to diverge from theirs for various reasons, so we took a branch of their project and both groups made unique changes to the library. Sometimes it happened that we would fix a bug and sometimes it would happen that they would add a new feature, so we frequently merged back and forth with each other.
You can see here that the results of merging from our branch to theirs should not necessarily be the results of merging from their branch to ours. Let's assume that there was a file where we added some new methods and maybe fixed a few bugs. And let's assume that they'd added a few different methods. When they merged our changes into their branch, they'd get a merge conflict and let's assume they took the bugfixes but did not take our new methods since they didn't need them. Now when we do a merge to get their changes into our branch, we still get a merge conflict - this allows us to take their methods into our file.
If TFS were to make some assumption about the merge from their branch into ours based on the results from our branch into theirs, it would be inaccurate.