解决二进制文件的Git冲突

我一直在使用Windows上的Git (msysgit)来跟踪我一直在做的一些设计工作的更改。

今天我一直在一台不同的PC上工作(使用远程repo brian),我现在正试图将今天完成的编辑合并到我笔记本电脑上的常规本地版本。

在我的笔记本电脑上,我使用git pull brian master将更改拉入本地版本。除了主InDesign文档之外,一切都很好-这显示为冲突。

PC上的版本(brian)是我想保留的最新版本,但我不知道什么命令告诉回购使用这个版本。

我试图直接复制文件到我的笔记本电脑上,但这似乎打破了整个合并过程。

有人能告诉我正确的方向吗?

233827 次浏览

您必须手动解决冲突(复制文件),然后像这样提交文件(无论您是复制它还是使用本地版本)

git commit -a -m "Fix merge conflict in test.foo"

Git通常会在合并后自动提交,但当它检测到自己无法解决的冲突时,它会应用它找到的所有补丁,并将其余的补丁留给您手动解决和提交。Git合并手册Git-SVN速成班博客条目可能会揭示它应该如何工作。

看到下面的帖子,你实际上不必自己复制文件,但可以使用

git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt

以选择所需文件的版本。只有当你想混合使用两个版本时,才需要复制/编辑文件。

请将米帕迪斯的答案标记为正确答案。

我遇到过一个类似的问题(想要提交一个包含一些二进制文件的提交,这在合并时引起冲突),但遇到了一个不同的解决方案,完全可以使用git完成(即不必手动复制文件)。我想我应该把它包括在这里,这样至少我下次需要的时候可以记住它。:)步骤如下:

% git fetch

这将从远程存储库获取最新的提交(您可能需要指定一个远程分支名称,这取决于您的设置),但不会尝试合并它们。它在FETCH_HEAD中记录提交

% git checkout FETCH_HEAD stuff/to/update

这将获取我想要的二进制文件的副本,并使用从远程分支获取的版本覆盖工作树中的内容。Git不会尝试进行任何合并,因此您最终得到的只是来自远程分支的二进制文件的精确副本。完成之后,就可以像平常一样添加/提交新副本了。

您还可以使用

git mergetool

这会导致git创建冲突二进制文件的本地副本,并在它们上生成默认编辑器:

  • # EYZ0
  • # EYZ0
  • # EYZ0

显然,在文本编辑器中无法有效地编辑二进制文件。相反,您可以在不关闭编辑器的情况下将新的{conflicted}.REMOTE文件复制到{conflicted}上。然后,当您关闭编辑器时,git将看到未修饰的工作副本已被更改,并且您的合并冲突已以通常的方式解决。

要解决这个问题,你需要将版本保存在当前分支中(忽略你正在合并的分支中的版本),只需添加并提交文件:

git commit -a

为了解决这个问题,你需要用你要合并的分支的版本来覆盖你当前分支中的版本,你需要首先检索那个版本到你的工作目录中,然后添加/提交它:

git checkout otherbranch theconflictedfile
git commit -a

详细解释

对于这种情况,git checkout接受--ours--theirs选项。因此,如果你有一个合并冲突,你知道你只是想从你合并的分支文件,你可以这样做:

$ git checkout --theirs -- path/to/conflicted-file.txt

使用该版本的文件。同样,如果您知道您想要自己的版本(而不是被合并的版本),则可以使用

$ git checkout --ours -- path/to/conflicted-file.txt

来自# EYZ0文档

# EYZ0

< p > # EYZ1 < br > # EYZ1 < br > 当从索引中检出路径时,对于未合并的路径,检出阶段#2 (ours)或#3 (theirs)

由于之前的合并失败,索引可能包含未合并的条目。默认情况下,如果尝试从索引中签出这样的条目,签出操作将失败,并且不会签出任何内容。使用-f将忽略这些未合并的条目。可以使用--ours--theirs将合并中特定一侧的内容签出索引。使用-m,可以丢弃对工作树文件所做的更改,以重新创建原始的冲突合并结果。

mipadi的回答对我不太管用,我需要这样做:

Git签出——我们的路径/to/file.bin

或者,保持被合并的版本:

Git签出——他们的路径/to/file.bin

然后

Git添加路径/到/file.bin

然后我可以再次使用"git合并工具"继续处理下一个冲突。

我遇到过在windows上使用Git管理二进制文件的差异/合并的两种策略。

  1. Tortoise git允许你根据文件扩展名为不同的文件类型配置不同/合并工具。看到2.35.4.3。Diff/Merge高级设置http://tortoisegit.org/docs/tortoisegit/tgit-dug-settings.html。当然,这种策略依赖于合适的差异/合并工具。

  2. 使用git属性,你可以指定一个工具/命令来将二进制文件转换为文本,然后让你默认的diff/merge工具来做它的事情。参见http://git-scm.com/book/it/v2/Customizing-Git-Git-Attributes。文章甚至给出了一个使用元数据区分图像的例子。

我让这两种策略都适用于软件模型的二进制文件,但我们使用了tortoise git,因为配置很简单。

如果二进制文件是比DLL更多的东西,或者像图像一样的直接编辑,或者混合文件(你不需要丢弃/选择一个文件或其他文件),真正的合并将是这样的:

我建议搜索一个diff工具,针对你的二进制文件,例如,有一些免费的图像文件

然后比较它们。

如果没有diff工具来比较你的文件,那么如果你有最初的发电机的bin文件(也就是说,存在一个编辑器它…)就像blender 3d一样,你可以手动检查这些文件,也可以查看日志,并询问其他人你应该包括什么) 然后用https://git-scm.com/book/es/v2/Git-Tools-Advanced-Merging#_manual_remerge

输出文件
$ git show :1:hello.blend > hello.common.blend
$ git show :2:hello.blend > hello.ours.blend
$ git show :3:hello.blend > hello.theirs.blend

我使用Git工作流的Excel - https://www.xltrail.com/blog/git-workflow-for-excel应用程序来解决我的二进制文件相关的合并问题。这个开源应用程序可以帮助我高效地解决问题,而不用花费太多时间,让我选择正确的文件版本而不会有任何困惑。

这个过程是在你向Github提交了一个pull请求后解决二进制文件冲突:

  1. 所以在Github上,你发现你的拉请求在二进制文件上有冲突。
  2. 现在回到本地计算机上相同的git分支。
  3. 您(a)再次重新制作/重新构建这个二进制文件,(b)将生成的二进制文件提交到相同的git分支。
  4. 然后你把这个相同的git分支再次推到Github。

在Github上,在你的拉请求时,冲突应该会消失。

我的案子看起来像个bug....使用git 2.21.0

我拉了一下…它抱怨二进制文件:

warning: Cannot merge binary files: <path>
Auto-merging <path>
CONFLICT (content): Merge conflict in <path>
Automatic merge failed; fix conflicts and then commit the result.

然后这里的任何答案都没有产生任何有意义的输出。

如果我看一下我现在拥有的文件……这是我编辑的。如果我这样做:

git checkout --theirs -- <path>
git checkout --ours -- <path>

我得到输出:

Updated 0 paths from the index

我还保存着我那份文件如果我rm,然后签出,它会说1,但它仍然给我我的文件版本。

Git mergetool说

No files need merging

git状态显示

    All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)

一个选项是撤销提交…但我很不幸,我犯了很多错误,这是第一次犯错误。我不想浪费时间重复了。

为了解决这个疯狂的问题:

我只是跑了

git commit

这会丢失远程版本,并可能浪费一些空间存储额外的二进制文件…然后

git checkout <commit where the remote version exists> <path>

这样就能把远程版本还给我了

然后再次编辑文件…然后提交和推,这可能意味着用另一个二进制文件的副本浪费空间。