Question

如果在使用文本编辑器无法解决的二进制文件或任何非文本文件中发生冲突，则应改用git checkout --theirs或git checkout --ours，然后将其添加到暂存区中。

但是，如果我什么都不做，请直接将那些未合并的二进制文件添加到暂存区域中，而不解决冲突，而不选择适当的版本，哪个版本将添加到暂存区域中？是我们的还是他们的？

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)

      both modified: test.bin
      both modified: test.a

Answer 1

有些时候适合检入二进制文件，图像，视频，办公文件...，但无法合并。您必须选择一个或另一个，或者制作一个新版本。

但是，这些看起来像是构建工件。在构建过程中生成的文件。这些不应该签入。它们的源代码将过时，并且在具有不同编译器和不同库的不同人员的计算机上，它们也将有所不同。

先用git rm然后再用add them to the project's .gitignore删除它们，这样它们就不会再出现。您可能需要忽略整个类的文件，例如*.a和*.o和*.bin。 gitignore.io可以为您的项目生成良好的起始忽略文件。

Answer 2

如果在使用文本编辑器无法解决的二进制文件或任何非文本文件中发生冲突，我应该改用git checkout --theirs或git checkout --ours ...

这不一定是正确的。与纯文本文件一样，有时正确的分辨率实际上是 combined 更改，某些二进制文件的正确分辨率可能是 combined 更改。只是 Git 不能为您做到这一点。正确执行此操作的唯一方法可能是找到一个或多个源文件，以及某种形式的源到二进制转换器。您可能需要组合源代码更改，将结果编译/转换为新的 third 二进制文件，然后使用它。

尽管如此，这个问题还是有答案的。研究和记住它可能毫无意义。

但是，如果我什么都不做，请直接将那些未合并的二进制文件添加到暂存区中...

git add的作用是将工作树中的所有内容复制到插槽0处的索引/登台区域，从而删除所有上级条目。在冲突期间，您拥有的是索引/暂存区域中的三个不同的二进制文件，但使用的是插槽1（合并基准），2（我们的）和3（它们的插槽）。

因此，这仅意味着将工作树文件复制到插槽0中，并删除插槽1、2和3中的条目。因此，问题与以下内容相同：

如果二进制文件发生冲突，Git在工作树中会留下什么？

the git merge documentation和the gitattributes documentation中都有答案。这使它难以阅读。

第一个关于recursive和resolve策略，说有其他个参数会影响结果。这些附加参数是-X ours和-X theirs参数，表示：

我们的
    通过支持我们的版本，此选项可以强制自动解决冲突的大块。与另一棵树不冲突的更改会反映到合并结果中。对于二进制文件，全部内容都是从我们这边获取的。
...
    他们的
    这与 ours; 相反；请注意，与 ours 不同，没有 theirs 合并策略可将此合并选项与之混淆。

gitattributes文档添加了以下内容：

执行三向合并
    ...
    属性merge影响在必须进行文件级合并时如何合并文件的三个版本...

，然后继续说大多数，“从工作树的分支中保留版本”。因此，通常工作树与index-slot-2相匹配，您可以通过执行git checkout-index --temp --stage=2 test.bin并将结果文件与test.bin进行比较来进行测试。

尚不清楚此类属性是否覆盖-X theirs；如果您设置自己的merge属性并使用-X theirs，则必须通过将工作树中的内容与索引插槽2和3中的内容进行比较来进行测试。

但是，通常，大多数方法通常会将“我们的”版本留在工作树中。如果合适，您可以使用git add将工作树版本复制回插槽0，并擦除插槽1-3，将文件标记为已解决。只要确保您已使用-X theirs和/或某种有趣的merge设置，您就知道自己在做什么，并仔细检查了所有内容。

（当然，您最好的选择是避免以这种方式合并二进制文件。）

在Git中标记为已修改的二进制文件的默认版本是什么？

2 个答案:

如果二进制文件发生冲突，Git在工作树中会留下什么？