Question

我有功能分支，我修改了文件 A /CMakeLists.txt 而在主分支上，执行了两个操作：

文件 A /CMakeLists.txt已修改并移至 B /CMakeLists.txt
新文件 C /CMakeLists.txt已创建

现在，当我将我的分支合并到master git时，坚持认为 B /CMakeLists.txt是一个新文件，并且 A /CMakeLists.txt已移至 ç /CMakeLists.txt。有了这个假设，它会尝试将我的更改合并到 C 中的文件而不是 B 。有没有办法告诉git在合并过程中它的猜测是错误的并命令它以不同的方式重新尝试？

Answer 1

更新评论信息

显而易见的是尝试“修复”合并的行为。这肯定可以做到，而且很可能是你应该做的。（有一个小的，潜在的下降[1]，但它可能是较小的邪恶。）

我能想到“调整”自动重命名猜测行为的唯一方法是改变相似性阈值;但这并没有真正帮助 - 因为git选择“错误”文件意味着“错误”文件“更相似”，所以增加阈值将消除“正确”文件，然后消除“错误”之一。

您可以完全禁用重命名检测，但随后您对分支的更改将转到A目录，这也不是我认为您想要的。

所以很可能无法找到git，因此它的自动行为变得正确。但是对我来说似乎更有希望的一个选择就是说，你知道，这不应该经常发生，所以手动修复可能没问题。

git merge --no-commit myFeatureBranch

合并结果将放在工作树和索引中，但不会提交，因此您可以调整结果。

git checkout $(git merge-base HEAD MERGE_HEAD) -- A/CMakeLists.txt
mv A/CMakeLists.txt tmp-BASE.txt
git checkout MERGE_HEAD -- A/CMakeLists.txt
git checkout HEAD -- B/CMakeLists.txt
git checkout HEAD -- C/CMakeLists.txt
git merge-file B/CMakeLists.txt tmp-BASE.txt A/CMakeLists.txt

这可能会导致B / CMakeLists.txt发生冲突，在这种情况下，您可以按正常合并解决它们。然后清理并完成合并：

rm A/CMakeLists.txt
rm tmp-BASE.txt
git add .
git commit

[1]修复合并的潜在问题：如果合并完成而没有冲突（但只是得到错误的结果），那么在修复合并之后，你将有一个排序“邪恶合并”。在这种情况下，它不是非常邪恶;合并结果有点模糊，接受的合并结果和默认合并结果之间的差异属于该歧义。理论上，如果重写的提交范围将通过合并，它可能会导致未来的rebase操作出现问题。

即便如此，另一种选择是以这样一种方式重写历史记录，即在创建文件C之前可以合并分支更改。这说起来容易做起来难得多，如果已经分享了任何受影响的历史记录，那么就会产生“上游反叛”问题。

所以...那就是完整性，如果它足以让你想要避免合并修复，那么接下来的步骤就是研究历史重写是如何工作的。

合并：相似索引错误命中 - 如何修复？

1 个答案: