使git在合并冲突时不修改本地文件

当git遇到合并冲突时，它的响应似乎总是通过在文件中添加冲突标记（也称为“行噪波”）来修改文件。有没有办法让它不那么做

我的第一个选择是让它完全不修改文件。非常接近的第二步是应用所有非冲突的编辑，并为冲突的编辑保留我的本地编辑。（在任何一种情况下，都要将文件的元数据标记为需要解析。）第三种最好的方法是，在发生冲突时，在修改任何本地状态之前，中止整个

pull

、

stash pop

等操作，就好像我从未尝试过那样

不管git做什么（它当前的默认设置或我的任何首选项），在冲突之后，我要做的下一件事就是在本地状态上启用一个diff工具，而不是一个干净的头部（如果需要，运行另一个

git clone

）。因此，它试图通过使冲突更容易发现来帮助我，实际上使冲突更难理解

在使用源代码管理将近20年的时间里，我还没有发现一种情况是git试图让我做的是处理冲突的最有效的方法。我能想到的唯一一种情况是，在40年前，像GUI和tmux这样的东西还不存在的时候，可能会更有用。即使如此，只有当我告诉它时，它才会继续进行，这对我的工作方式是一种改进

编辑：

---

@mkrieger1指出，

-Xours

，至少就文件内容而言，是我的选项2。但他们的话听起来似乎会吞噬冲突，让我冒着找不到和解决它们的风险

@qneill指出了一种获得“干运行”效果的方法，即选项3，但我真正想要的是在合并操作失败时使用不同的文件内容。

您可以使用“我们的”选项作为递归合并策略（默认策略），方法是使用

git merge-Xours

：

此选项强制冲突块由 支持我们的版本。其他树中不冲突的更改 与我方的合并结果都有所反映。对于二进制文件， 全部内容都是从我方取来的

正如上面所说的

这不应该和我们的合并策略相混淆，我们的合并策略确实如此 根本不看另一棵树包含什么

---

您可以通过

git merge--

调用它。主要问题是检测git中冲突的唯一方法是运行操作并检查结果

这似乎与和有关

您的选项#1“完全不修改文件”-但标记为冲突

最简单的方法是运行

git merge

，然后使用

git checkout--ours

修复内容，以获取冲突文件的头版本，同时保持其冲突状态：

$ git checkout REF1
$ git merge REF2
### git fails here with a conflict
$ git status

$ git diff --name-status --diff-filter=U | 
  awk '{print $2}' |
  xargs git checkout --ours --

$ git diff HEAD
$ git status
### no diffs for unmerged files but still marked as unmerged

仅供参考：未合并文件的其他版本可以使用

git checkout--ours--

签出头部版本，

git checkout--theres--

签出合并头版本，以及

git checkout--MERGE--

签出带有冲突标记的合并内容

您的选择#2

我不确定选项1和选项2之间的区别。。。如果“应用所有不冲突的编辑”是指对其他文件的更改，那么上面的答案可以做到这一点。如果您的意思是对冲突文件进行更改（保留那些不冲突的文件，清除那些存在冲突的编辑），则需要解析和后处理冲突文件

您的选项#3试运行-“中止整个过程，就像从未尝试过一样”

您可以使用

--no commit

（对于

合并

和

拉动

）来设计一个侵入性更小的测试（清理更少）。但问题仍然出现在如何恢复原始状态上，即如果操作失败，那么是

git merge--abort

，或者如果一切正常，那么是

git reset HEAD@{1}

这里我假设REF1是您想要开始的地方

$ git checkout REF1
$ git merge REF2
$ if [ $? -ne 0 ] ; then
>     echo "conflicts"
>     git ls-files -u     ## or 'git status'
> else
>     echo "merged cleanly"
> fi
$ git reset --hard REF1

---

当您启动一个合并时，您是在告诉Git将这些东西混合在一起。如果这不是你想要的，不要合并。你可以从一个简单的步骤开始：创建一个新的分支。然后初始化合并，记笔记，搞乱它，删除临时分支（返回原始分支）=>合并期间和/或合并之后没有修改您的文件。@SandraK如果要替换像

git pull

或

git stash pop

这样简单的东西，这将是一个有点复杂的工作流。“让我冒着找不到和修复它们的风险”-冲突标记，您不想要的，正是在那里帮助您找到和修复冲突。@mkrieger1只有当我知道查看文件（元数据状态指示）时，这些标记才起作用，一旦我知道，我就不需要它们（无论如何，我将检查所有内容）。我认为OP想要”测试合并“并查看是否会发生冲突，但保持文件不变。如果我读取的正确，这将实际解决合并问题。”。这不是我想要的。如果存在冲突，则文件仍应显示为未解决。不过除此之外…@qneill，你的建议是我的第三个选择。当然，运行操作来检测结果是可以的。我想要一个

--试运行

选项，但那是另一个问题但我在这里要求的是，对于文件内容而言，遇到合并冲突的操作的结果是

-Xours

（感谢mkrieger1），但对于元数据而言，将文件标记为未解决。。。为了使这一点在任何时候都成为事实，它尝试合并。我不想每次都记住传递这些标志，也不想搜索到每一个可能需要它们的git命令