为什么我不能在冲突状态下提交更改？

Question

众所周知，在subversion (或任何其他版本控制系统)中合并分支经常会导致冲突。有时，这些冲突可能很难解决。但是，在将更改提交到存储库之前，您需要这样做。

由于合并本身显然将应用一组更改，因此任何解决冲突的修改都将应用于这些更改之上。最后，不可能将来自自动合并的更改与应用于解决冲突的手动修改分开。

在合并时引入问题并不少见，这不仅是因为集成本身的挑战，而且是因为解决合并冲突时的错误决策。如果在解决任何冲突时做出的决策在单独的提交中都清晰可见，那么快速跟踪这些问题会更容易。让同事检查你为解决冲突所做的工作也会更容易。

如果允许在冲突状态下提交更改，这将是可能的。可以先提交包含冲突的自动合并，然后再提交冲突解决。

显然，您可以争辩说，让存储库处于冲突状态是不可取的，但您可以始终让客户端访问最后一个未冲突的修订版本。我宁愿让一个存储库偶尔处于冲突状态，而不是一个被错误的合并解决方案破坏的存储库。

为什么我不能在冲突状态下提交更改？

可选:我是否遗漏了一些subversion魔法，有没有工具可以找出解决冲突的决定？

可选: git或任何其他版本处理系统是否比subversion更好地处理此问题？

Answer 1

想一想你的存储库处于冲突状态意味着什么。这意味着有不止一个正确的最新版本的代码，这意味着您已经派生了存储库。源代码控制系统已经有了可以用来派生存储库的方法。

如果你真的不知道合并冲突的解决方案是什么，你就是在派生你的代码，所以你应该做一个适当的派生，而不是试图在你的源代码控制系统中实现某种伪或准派生！