GIT：git checkout --ours 仍然显示“两者都已修改”

Question

我正在尝试解决某些文件中的合并冲突

both modified:   myFile.h

我运行了这个命令：

git checkout --ours myFile.h

之后我跑了：

git status

它显示了这一点：

both modified:   myFile.h

为什么还是显示“两者都修改了”？

Answer 1

一些git checkout命令会解决合并冲突，采用您检出的版本，而另一些则不会。这是没有的情况之一。

因此，您必须手动将冲突标记为已解决，使用：git add myFile.h。

为什么是这样

合并（动作，即merge-as-a-verb）是通过Git 的索引（也称为暂存区或有时称为缓存）完成的。对于将进入您进行的下一次提交的每个文件，索引都有一个条目。通常，一个条目保存一个文件——但索引每个条目有四个插槽，它们被编号。插槽零 ( 0) 是正常的“无冲突，文件已准备好提交”插槽。插槽 1、2 和 3 仅在合并冲突期间使用，并且包含合并基础版本（插槽 1）、--ours版本（插槽 2）和--theirs版本（插槽 3）。

如果插槽 0 已填充，则其他三个插槽为空。如果任何其他插槽已填充，则插槽 0 为空且文件处于“冲突”状态。（可以只填充其他三个插槽中的两个，就像添加/添加、修改/删除和重命名/删除冲突一样。）

当您运行，^1个Git的副本从给定的文件提交到插槽零，然后从插槽零到工作树。复制到插槽 0 会清除插槽 1-3（如果它们已满），因此文件现在已解析！git checkout commit -- path

但是，当您运行 时，Git 不必为索引槽 0 写入任何内容，它只需从槽 2 获取文件的内容。因此它从槽 2 复制到工作树，并且文件未解析。git checkout --ours -- path

请注意，这意味着您可以从提交中提取文件，写入插槽零，从而解析以及写入工作树。不过，这在另一种方式上略有不同。假设在合并期间，Git 决定文件被重命名以及被修改。它考虑了重命名：文件的新名称而不是旧名称。如果你，Git 将在新名称下提取旧（HEAD）版本。如果你，Git 将找不到新名称下的文件！git checkout HEAD -- pathHEADevil/zorgevil-zorggit checkout --oursevil-zorgevil/zorggit checkout HEAD

（这是 Git 让实现细节显示出来的另一种情况——或者，等效地，将太多东西塞进一个命令中。）

¹的原因--是处理一个名称看起来像一个选项的文件。（例如，如果文件名是--theirs？）如果路径部分看起来不像一个选项，则不需要--. 不过，这是一个好习惯：--每次都使用它，有一天当您的文件名确实类似于一个选项时，您不会感到惊讶。