合并没有冲突，代码无法编译：我应该在提交之前修复它吗？答案

【问题标题】：Merge with no conflicts, the code doesn't compile: should I fix it before commit?合并没有冲突，代码无法编译：我应该在提交之前修复它吗？
【发布时间】：2015-07-06 15:50:56
【问题描述】：

我正在使用 Subversion 1.7.x，并且正在分支上进行我的开发。

我不时从 trunk 合并以保持分支处于最新状态。
然而，在最近的合并期间，传入的代码虽然在 trunk 中完全正确，但在 branch 中却没有编译。
这是意料之中的，因为在 trunk 中更改的代码已在数次修订前在 branch 中部分重写。

请注意，合并操作干净地完成，没有冲突。
为了清楚起见，当我说 merge 时，我的意思是使用来自另一个分支的代码修改工作副本的操作，不涉及提交，即只是 svn merge [source] [dest]。

既然那个branch最终会重新整合到trunk，我想我有两个选择：

在提交合并代码之前修复编译错误；
从主干合并；提交（未经编辑的合并代码）；编辑代码以修复编译问题；再次提交（即随后修复编译问题，执行新的单独提交）。

如果我在提交之前编辑合并的代码（即我选择#1），重新集成分支时这些更改会丢失吗？

【问题讨论】：

好问题，虽然它主要是基于意见的，可能会被关闭。可能更适合programmers.stackexchange.com
@PatrickQuirk 嗯...不是我想要的那样：我担心重新集成时是否会保留编辑预提交...我会改写这个问题。
@PatrickQuirk 如果一个问题在这里主要是基于意见的，这同样适用于程序员（我们有相同的密切原因）。请阅读：What goes on Programmers.SE? A guide for Stack Overflow。话虽如此，我不确定这个问题主要是否基于意见。一组专家可能会达成共识。
我投票决定将此问题作为题外话结束，因为它应该被迁移到 Programmers.SE，但它会作为 Is it good idea to require to commit only working code? 的副本被关闭
@watery 我不认为这是基于意见的。我认为这是一个很好的、可以回答的问题，我只是认为如果它被迁移它会是重复的。如果您认为它不是重复的，请随时编辑它的不同之处。在这种情况下，SVN 与 CVS 的区别还不够。

标签： svn version-control svn-merge

【解决方案1】：

简短的回答是：不，更改不会丢失。

更多细节。
重新集成合并不同于“常规”同步合并，因为它将分支复制到主干，因此两者变得相同[1]。它可以表示为“将分支和主干之间的差异应用到主干（wc）”。当然重新整合合并实际上应该是重新整合合并。 Subversion 1.8 以某种方式猜测，早期版本在合并期间需要 --reintegrate 参数。

更新：

[1] 实际上，我做了几个测试，发现只有当您合并到更新到上次同步修订的工作副本时，结果才会相同。例如，如果您将主干 1-100 同步到分支，然后在主干 10 中创建更多附加修订，然后将分支重新集成到主干 - 这可能会有所不同。

我个人更喜欢同步分支而不是主干中的最新版本，重新集成然后比较文件夹的二进制身份。以防万一:)

【讨论】：

感谢您提供的有用提示。是的，我在重新集成之前也将分支与最新的主干对齐。