众所周知，在subversion（或任何其他版本控制系统）中合并分支通常会导致冲突。有时这些冲突可能非常复杂。但是，在将更改提交到存储库之前，您需要这样做。
由于合并本身显然会应用一组更改，因此解决冲突的任何修改都将应用于这些更改之上。最后，不可能将自动合并的更改与用于解决冲突的手动修改分开。
在合并时引入问题并不罕见，这不仅是由于集成本身的挑战，而且是在解决合并冲突时的错误决策。如果在解决任何冲突时做出的决策在单独的提交中清晰可见，那么快速跟踪这些问题会更容易。让同事回顾您为解决冲突所做的工作也会更容易。
如果允许在冲突状态下提交更改，则可以执行此操作。包括冲突在内的自动合并可以先提交，然后再解决冲突。
显然，您可能会认为将存储库置于冲突状态是不受欢迎的，但您始终可以让客户端访问最后一次未受冲突的修订。我宁愿每隔一段时间就有一个处于冲突状态的存储库，而不是由于错误的合并解析而导致存储库崩溃。
为什么我不能在冲突状态下提交更改？
可选：我是否遗漏了一些颠覆魔法，是否有工具可以找出解决冲突的决策？
可选：git或任何其他版本处理系统是否比subversion更好地处理这个？
答案 0 :(得分：2)
考虑存储库处于冲突状态的意味着什么。这意味着有多个可能的正确最新版本的代码，这意味着您已经分叉了存储库。源控制系统已经具有可以分叉存储库的手段。
如果你真的不知道合并冲突的解决方案是什么，那么你就是在分叉你的代码，所以你应该做一个正确的分叉而不是试图在你的源代码中实现某种伪或准分叉控制系统！