我正在尝试解决某些文件中的合并冲突
both modified: myFile.h
我跑了这个命令：
git checkout --ours myFile.h
git status
它显示了这个：
both modified: myFile.h
为什么仍然显示“两个都被修改”？
答案 0 :(得分：3)
某些git checkout命令解决了合并冲突，使用您签出的版本，有些则没有。这是其中一个没有的情况。
因此，您必须手动将冲突标记为已解决：git add myFile.h。
合并（动作，即合并为动词）是通过Git的索引（也称为临时区域或有时是缓存）完成的）。索引有一个条目用于每个文件，这些条目将进入下一次提交。通常，一个条目包含一个文件 - 但索引每个条目有四个 slot ，这些条目已编号。插槽零（0）是正常的“没有冲突，文件已准备好提交”插槽。插槽1,2和3仅在合并冲突期间使用，并包含合并基础版本（插槽1），--ours版本（插槽2）和--theirs版本（插槽3）。
如果插槽零已填满，则其他三个插槽为空。如果填充了任何其他插槽，则插槽0为空并且文件处于“冲突”状态。 （可能只填充其他三个插槽中的两个，就像添加/添加，修改/删除以及重命名/删除冲突一样。）
运行git checkout commit -- path时， 1 Git将文件从给定的提交复制到插槽零，然后从插槽零复制到工作树。复制到插槽零会擦除插槽1-3，如果它们已填满，则文件现在已解决！
但是，当您运行git checkout --ours -- path时，Git不必编写任何内容来索引插槽零，它只能从插槽2获取文件的内容。因此它从插槽2复制到工作树，并且该文件未已解决。
请注意，这意味着您可以执行git checkout HEAD -- path从HEAD提交中提取文件，写入插槽零，从而解析以及写入工作树。不过，这在另一方面略有不同。假设在合并期间，Git决定该文件重命名以及被修改。我们将重命名考虑在内：文件的新名称为evil/zorg，而不是旧名称evil-zorg。如果您git checkout --ours，Git将以新名称evil-zorg提取evil/zorg的旧版（HEAD）。如果你git checkout HEAD，Git将无法以新名称找到该文件！
（这是Git的另一个案例，让实现细节显示通过 - 或者等效地将太多东西塞进一个命令中。）
1 --的原因是处理名称看起来像一个选项的文件。 （例如，如果文件名是--theirs怎么办？）如果路径部分看起来不像一个选项，则不需要--。不过，这是一个好习惯：每次都使用--，当你的文件名 类似于选项时，你不会感到惊讶。