2

我有一个关于解决合并冲突的“最佳实践”问题。

假设我有 master 并且需要将一个功能分支合并到其中，它引入了日志记录工具。此外，假设在合并期间，我遇到了冲突，因为 master 中的一些打印语句被修改，这些语句被功能分支中的日志语句替换。

现在，在手动合并解决期间，您是否说允许解决冲突的人也替换与日志记录相关但尚未在功能分支中处理的代码？例如，在包含冲突的代码块中，master 中还添加了一条新的打印语句。由于它还没有在功能分支中，它将保留在合并的代码中，除非有人用正确的日志语句替换它。

还是应该合并只触及实际冲突，将上述所有不一致留给未来的提交？

4

2 回答 2

3

我永远不会在合并中做出改变。

  • 该代码尚未经过任何测试。不应提交未经测试的代码。
  • 您可能会掩盖由合并本身引起的错误。至少通过合并，您知道您有 2 个工作分支。
  • 当其他人查看历史记录时，他们会看到发生了合并，不会期望进一步的代码更改。
  • 区分代码更改和合并比区分更改或合并本身更困难。
  • 如果您在合并中执行此操作，则无法自动回滚您的不一致修​​复，您将不得不回滚所有内容并重新合并。

进行合并，然后进行更改，否则您会感到痛苦和困惑。

于 2010-11-12T20:27:07.120 回答
1

我建议在合并期间，您只更改与合并相关的代码。然后，一旦合并完成，返回并修复不一致的地方。

您绝对不想将不一致的地方留给其他人处理，因为其他人可能需要很长时间才能注意到它们。

于 2010-11-12T20:25:05.317 回答