Git 合并冲突实践

Question

我认为这是一个非常小的问题，但我想知道是否有关于该主题的任何实际文档，或者甚至可能有理由的意见。

在处理合并冲突时，是不是更好

1. 仅使用 git 提交合并解析，然后 构建和测试，如果您在合并重置 HEAD 方面犯了错误 返回一个并重复合并决议，以便唯一的事情 changed 可以追溯到 branch1 或 branch2 但它可能 需要更长的时间。

2. 解决冲突，保持未提交状态，构建并转到编辑器以在 IDE 中手动修复合并错误，一旦构建 提交合并。更快，但并非每个更改都可以追溯到 分支。

3. 给猫剥皮的方法有很多种，不管是不是 在合并之前，更改在或不在任何一个分支中。
4. 另一个选项未列出

Answer 1

这是一个非常好的问题，对于重新定位分支的情况，它变得更加复杂。单个变基操作可能涉及在目标分支之上重新提交 多个 提交。这些提交中的每一个都可能会引入错误。我从未听说过有人在变基或合并中为每次提交执行完整的构建和测试周期。

我想说，最佳做法是在修复错误的合并或变基后进行一些额外的提交。这样，您就可以清楚地了解实际发生的情况。从关注点分离的角度来看，拥有这样的历史也有帮助。如果您需要恢复合并后的错误修复，使用这种方法会很简单。如果您将错误修复与合并提交一起滚动，则会更加困难。