有没有办法说“对于所有剩余的合并冲突”，选择“我们的”作为合并冲突解决方案？在我的情况下，“我们的”也是删除，而不是编辑。
我正在使用 Git Extensions，并进行了一些命令行工作。当我进行合并时，我会经历一系列复杂的过程来解决合并问题。对于一个进程，总是会有一组文件在合并中发生冲突，因为在我的分支上，我正在删除它们。
通常，我运行合并，查看是否存在冲突，然后从我的存储库中删除特定文件，同时适当地合并一些其他有冲突的文件。
然后，当我确定我的本地文件系统正确时，我进入了 Git 扩展，并在每个合并冲突的文件上选择了合并，并选择了“我们的”（已删除）......一个接一个...... （Git Extensions 不允许我进行多选）。有很多文件......所以我正在寻找一种方法，一旦我完成其他合并，我基本上可以对所有剩余的合并冲突进行批量“合并 - > 我们的”。
我不知道如何在 GUI 中执行此操作，但在命令行中：
git checkout HEAD -- path1 path2 path3 path4 ...
（采用“我们的”版本）或：
git checkout MERGE_HEAD -- path1 path2 path3 path4 ...
（采用“他们的”版本）。
如果“我们的”版本是删除（如您的描述），只需：
git rm path1 path2 ...
使用“解决方法是删除文件”设置索引。
编辑（在两条评论后）添加：git checkout --oursandgit checkout --theirs也可以用来代替git checkout HEADand git checkout MERGE_HEAD。区别（有一个）是微妙的：当您处于冲突合并的中间时，索引包含暂存槽 1、2 和/或 3path中存在冲突的每个条目。对于不冲突的路径，索引只有一个零阶段条目。签出--ours或--theirs提取暂存条目，同时从指定的提交（更准确地说，从与提交关联的树）签出HEAD或提取文件。MERGE_HEAD
第 1 阶段条目是合并基础，第 2 阶段是--ours，第 3 阶段是--theirs。如果冲突与修改有关，则使用所有三个暂存槽。如果冲突是 delete-vs-modify，则暂存槽 1 正在使用，但其余槽之一未使用。如果冲突是 create-vs-create，则插槽 1 为空，而插槽 2 和 3 已填充。
执行git rmorgit checkout清除冲突暂存槽并使用已解决的结果填充正常的 stage-0 条目。Git 仅在没有剩余阶段冲突时才允许最终合并提交（仅git ls-files --stage显示阶段 0）。
讨厌 GUI 的众多原因之一是他们可能拒绝重新检查索引，认为他们知道什么是最好的（而且他们从来不这样做）。如果您是这样，它可能会忽略您所做的所有 CLI 解析，并要求每个解析都通过 GUI 本身。