如何解决由.dll文件引发的Git合并冲突问题？

嘿，这个场景太常见了——二进制文件（比如.dll）没法手动编辑冲突，Git又没法自动合并，确实头疼。既然你的目标是让master分支和fix35完全一致，这里有几个直接可行的解决方向：

方法一：直接覆盖冲突文件（最直接） #

如果还没开始处理冲突，先取消当前的合并操作：

git merge --abort

然后直接从fix35分支拉取那4个冲突的.dll文件到当前master分支：

git checkout fix35 -- path/to/conflict1.dll path/to/conflict2.dll path/to/conflict3.dll path/to/conflict4.dll

把这些文件加入暂存区：

git add path/to/conflict*.dll

最后完成合并提交：

git commit

Git会自动生成合并提交的默认信息，直接保存即可。

方法二：在合并过程中直接取fix35的版本 #

如果已经进入了冲突状态（不想取消合并），可以用--theirs参数指定使用fix35分支的版本（因为fix35是你要合并的来源分支，Git里"theirs"指的是待合并的分支）：

# 对每个冲突的.dll文件执行
git checkout --theirs path/to/conflicted.dll

全部处理完后，同样把文件加入暂存区并提交：

git add path/to/conflict*.dll
git commit

预防措施：提前配置二进制文件的合并策略 #

为了避免以后再碰到类似问题，可以在项目根目录的.gitattributes文件中添加规则，告诉Git遇到.dll冲突时自动采用指定分支的版本。比如如果以后你经常从fix类分支合并到master，希望优先用fix分支的版本，可以加：

*.dll merge=theirs

如果是希望优先保留当前分支（比如master）的版本，则用：

*.dll merge=ours

添加后保存.gitattributes文件，提交到仓库即可生效。

小提醒 #

执行前一定要确认fix35分支的.dll文件是最终正确的版本，因为这些操作会直接覆盖master分支上的对应文件，一旦提交就没法轻易恢复啦。

内容的提问来源于stack exchange，提问作者Ranger 22