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

【问题标题】：Why can't I commit changes in a conflicted state?为什么我不能在冲突状态下提交更改？
【发布时间】：2017-02-21 08:17:51
【问题描述】：

众所周知，合并 subversion（或任何其他版本控制系统）中的分支经常会导致冲突。有时，这些冲突的解决可能非常复杂。然而，在将更改提交到存储库之前，您需要这样做。

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

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

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

显然，您可能会争辩说不希望存储库处于冲突状态，但您始终可以让客户端访问最后一个未冲突的修订版。我宁愿每隔一段时间有一个处于冲突状态的存储库，而不是一个被不正确的合并解析破坏的存储库。

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

可选：我是否缺少一些颠覆魔法，是否有工具可以找出解决冲突的决策？

可选：git 或任何其他修订处理系统是否比 subversion 处理得更好？

【问题讨论】：

【解决方案1】：

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

如果您真的不知道合并冲突的解决方案是什么，那么您就是在分叉您的代码，因此您应该进行适当的分叉，而不是尝试在您的源代码控制系统中实现某种伪分叉或准分叉！

【讨论】：

我不确定我是否同意。为什么这意味着有不止一个可能的正确最新版本？ HEAD 版本显然是最新版本，通过提交合并，无论是否存在冲突，都表明意图是将这些更改带入分支。如果存在未解决的冲突，则意味着还有集成工作要做。就像还有一些与版本处理系统无关的集成工作要做。