我遇到过一个案例merge默默地忽略合并分支的一些更改，这是我所期望的（rebase会带走他们）。
案例如下：
* merge slave into master: line not back
|\
| * oops, was bad, put the line back (slave branch)
| |
| * slave branch, also delete the same line
* | master branch, delete a line
|/
* initial
合并时slave into master，该行仍然被删除，因此将其放回原处的提交未被合并。变基会。
如果该行没有被删除而是被修改，这将是一个冲突，这对我来说很好。变基会接受回线，也很好。但是在没有任何警告的情况下跳过提交...我想知道它是针对哪些情况设计的。
注意：在网络上搜索类似的问题发现了很多......但都涉及在合并之前删除的整个文件。我可以承认这样做的原因，即使我更愿意发生冲突（而不是失去提交）。然而，对于文件内部的更改，我发现这更令人不安，并且没有发现任何提及。
注意：我在 Mercurial 上检查过，结果相同，这不是 Git 特有的。
原因是（文件级）合并看不到更改的路径；它看到该文件的三个版本：base, ours, and theirs.
在分支删除一条线然后将其放回去的情况下，theirs and base是相同的（至少在相关行上）。事实上，在历史的某个地方theirs，合并工具不知道这些行不会相同。
So for theirs该线路不是已更改的大块的一部分；但对于ours是的，所以改变ours被接受。
我同意这不是您想要从这个特定的合并中得到的，但我看不出任何合理有效的方法可以做得更好。另外，在 18 年以上的编程生涯中，我从未遇到过这种情况 - 所以“令人不安”可能有点重。
（我还想指出，您将此描述为“丢失提交”并不准确。提交was包含在合并结果中，只是以适得其反的方式。最重要的是，自动合并算法永远不可能完美；但我们使用的大多数时候都非常好。）
我想如果你really想要记住分支考虑如何处理该线路并决定保留它的事实，您可以对恢复的线路进行一些“无意义”的更改。然后，正如您注意到的更改行的情况，它将出现冲突。
但实际上，您运行了单元测试，不是吗？如果这一行足够重要，足以在两个更改行中删除并在其中一个更改行中重新添加，那么如果处理错误，您肯定有一个测试用例会失败吗？你知道测试你的合并结果，对吗？
重点是，这对于该工具来说不是一个好的行为……但它是一个rare无论如何，应该在成熟的开发过程中发现并纠正不良行为。我不会对此进行太多解读。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
