是否有理由在签入代码中保留冲突标记？

考虑冲突标记。即：

<<<<<<< branch
blah blah this
=======
blah blah that
>>>>>>> HEAD

在促使我提出此问题的特殊情况下，负责的团队成员刚刚完成了从上游到我们分支的合并，并在某些情况下将其留为注释，以作为刚刚过去的文档解决。他将其置于编译状态，测试通过，因此它没有您想的那么糟糕。

尽管本能地，我真的对此表示反对，但是作为恶魔的拥护者，我可以理解为什么他会这样做：

• 因为它向其他团队开发人员强调了合并带来的变化。
• 因为那些在特定代码方面更精通的人然后可以解决注释所说明的问题，从而使他不必猜测。
• 因为上游合并是很痛苦的事情，并且可能难以证明有时间妥善解决所有问题的时机，所以需要一些半完全的FIXME通知，因此为什么不使用原始冲突作为注释来记录此问题。

我的反对是本能的，但我希望能够合理地证明其合理性，或者更明智地看待我的立场。任何人都可以给我一些例子，甚至是一些经历，其中人们与其他人在一起做得不好，和/或为什么这样做不好的原因（或者您可以扮演魔鬼的拥护者并予以支持）。

我自己直接担心的是，如果我一直在编辑有关文件之一，拉出更改，遇到真正的冲突，但也加入评论的文件，那显然会很烦人。那我确实会有一个非常混乱的文件。幸运的是，这没有发生。

这显然是错误的。跟踪更改是版本控制系统的工作，而diff工具的工作是显示合并后已更改的内容。在提交日志中，也许在代码中也应该有注释，以说明更改内容和原因。但是，恕我直言，将冲突标记保留为注释与保留无效代码相同。

我也遇到过类似的问题，有些代码要么被注释掉了（这在某种程度上与您的情况类似），要么移到了一个实际上未在任何地方调用的方法。当被问及为什么人们这样做时，他们的回答是，当仍然有一些代码块时，他们会感到安全一些。最明显的反驳是，这是VCS的工作，而不是他们的工作。但是，还有另一方面。当其他人在学习或进行更改时正在阅读代码时，他可能会被这样的评论所困扰。他一定会读的，也许会花一些时间来了解为什么会出现在这里，以及与他目前的工作有什么可能的联系。由于冲突标记表示已经解决了冲突，因此肯定浪费时间。

我认为注释应该指代那里的代码，而不是指过去曾经存在的代码，也不应该指代过去某个时间发生在代码中的事件，也不应该指代存在于并行Universe（另一个分支）中的代码。过去。留下标记的方式至少会导致三个问题：

1. 原始代码可能类似于blah blah null，并且错误报告说“不能在那里使用null，使用this或that或其他方法。” 因此，两个人独立修复了该错误，并在合并了这些修复程序后，出现了冲突。现在，注释不记录问题是什么，也不记录修复程序，而只是记录了过去某个时候有两个不同的修复程序。那不是很有帮助。像//blah blah needs a non-null argument这样的注释将至少指示更改的内容（甚至更容易从版本控制系统的提交注释中获得该信息）。
2. 合并的版本可能甚至看起来都不像原始行之一。也许，如果您想等等，正确的格式blah blah (this,that)甚至更复杂。在这种情况下，将冲突消息保留为注释肯定会使以后尝试阅读代码的任何人感到困惑。
3. 大多数版本控制系统使您可以访问项目历史记录。例如，我可以右键单击eclipse中的文件（带有svn），说“显示历史记录...”，然后说“比较当前与...”，然后得到一个突出显示差异的差异窗口。如果差异突出显示中包含实际差异，而不是周围的注释，则更容易理解。

签入代码中的冲突标记有多烦人？

所以讨厌。