git - "-X theirs"选项似乎不适用于某些 Git 冲突

Question

这是一个烦人的。

我用这个命令 merge 两个分支

git checkout -b temp public/master
git merge -Xtheirs --squash -m "squashed with devtemp" devtemp

我遇到了一些冲突:

CONFLICT (rename/delete): public/github.css deleted in devtemp and renamed in HEAD. Version HEAD of public/github.css left in tree.
Removing public/extra-html/exit-codes.html
Removing public/.gitkeep
Auto-merging package.json
Squash commit -- not updating HEAD
Automatic merge failed; fix conflicts and then commit the result.

怎么能忽略这种类型的冲突？我虽然 --theirs/--ours (或任何适用于这些命令的正确 Git API)可以解决此类问题？有没有更好的实际工作方法？

Answer 1

-X theirs 策略参数仅针对一个文件中的单个冲突指导 merge 的冲突解决方案，而不是针对高级别的全文件冲突。

在这种情况下，正如消息所说，冲突是“他们”( devtemp )完全删除了 public/github.css ，而“你”( HEAD )重命名了它。您的 Git 不知道在此做什么，并以新名称保留了该文件。

如果你想做他们所做的，只需 git rm 新名称下的文件，以便将其删除。但是...请注意，重命名是通过内容相似性检测到的，因此它们可能根本没有真正删除该文件，而是删除了另一个文件，其内容(在删除之前)与您创建的新文件非常相似。在这种情况下，删除文件可能是错误的。

在所有情况下，无论何时进行 merge ，在提交之前测试结果都是明智的。将 -X 与 ours 或 theirs 一起使用时尤其如此。 Git 不知道它在组合什么，仅依赖于文本相似性，并且可以进行无意义的 merge ，尤其是在发生冲突的情况下盲目偏袒一方但在这些更改不冲突的情况下使用双方的更改时(这就是 -X选项做)。

由于您正在运行 git merge --squash ，它出于某种原因抑制了最终的 git commit 无论如何(a la git merge --no-commit )，您已经期望必须单独运行 git commit 。只需解决冲突(并一如既往地彻底测试)并提交。

编辑 (根据评论):如果您想以编程方式执行此操作(尽管我不建议这样做)，您可以使用 git ls-files --stage(也许使用 -z 以获得更好的机器可读输出)。任何非零阶段条目都意味着 merge 失败。索引的内容会告诉你发生了什么:

基本版本存在，我们的存在，他们的不存在:重命名/删除冲突，其中 Git 保留了“我们的”重命名版本。删除我们的( git rm -- <path> )以进行“他们的”删除。

基本版本存在，他们的存在，我们的不存在:重命名/删除冲突，其中我们删除了文件但他们重命名了 Git。工作树可能(我没有测试过)在他们的名字下有这个文件。添加它 ( git add -- <path> ) 以对其进行重命名。 (您需要设置一个测试用例并验证这是正确的路径。)

基本版本不存在，他们的存在，我们的存在:创建/创建冲突。 Git 无疑将我们的文件版本保存在树中。使用 git checkout --theirs -- <path> 将它们的版本提取到工作树，然后使用 git add -- <path> 切换到它们的版本。

我认为，这应该涵盖所有 Unresolved 案例。或者，如果您遇到从来没有任何实际重命名的情况，您会从 Git 的重命名检测代码中得到错误命中，并且您需要 -X no-renames 来禁用它。