如果存在冲突，是否阻止git pull修改文件？

当我运行

git pull

并出现冲突时，

git

将“冲突标记”插入到我的文件中，并将文件状态设置为某种挂起的合并或某些sutch。就我个人而言，我觉得这真的很烦人，因为我有更好的方法来解决冲突，而不是试图从一个简单的文本文件中解码它所认为的合并

有没有办法阻止git生成这些标记？具体地说，我希望所有命令，包括一个裸的

git pull

，在发生冲突时都不做任何事情，不管事情从什么状态开始

言下之意，我想要的是对git配置的更改。对我的工作流程的更改（例如“总是在拉之前提交”）不是我想要的

---

理想情况下，如果它不能进行完全干净的合并，我希望它对我的本地文件完全不做任何处理，而只是打印一个错误并告诉我自己修复它。

有几种方法可以解决这个问题

首先是要习惯它。这些是大多数合并工具使用的标准冲突标记。你会经常见到他们

[我想解决冲突]使用已在另一个窗口中打开的编辑器

一个好的编辑器会看到文件在磁盘上的更改，并显示冲突的版本。如果您的编辑器不这样做，可能是一个配置选项，或者是时候使用一个具有更好文件系统意识的新编辑器了。许多编辑理解这些标记，并将提供语法着色和其他帮助，例如，所有这些都是开箱即用的

如果有您喜欢的合并工具，您可以通过配置然后在发生冲突时运行

git mergetool

来使用它。Git将启动您配置的合并工具，您可以使用它来解决冲突。这包括在编辑器中打开文件

如果现有的mergetool适配器不能满足您的需要，您可以编写一个。请看一个例子，还有

---

首先，有各种方法可以避免git pull上的冲突

一个是不向

主机

作出任何承诺。而是在要素分支中完成所有工作。这些是您为处理单个功能或bug而创建的分支。即使是简单的。他们将你的工作与其他人的工作隔离开来，直到你完成为止。在分支中工作，直到功能完成

# After `git checkout -b feature` and some commits.
          [origin/master]
A - B - C [master]
         \
          D - E - F [feature]

同时，您可以在

master

上

git pull

随时更新。没有本地更改，就不会有冲突

# After `git pull` on `master` to get other's work.
                  [origin/master]
A - B - C - G - H [master]
         \
          D - E - F [feature]

您可以使用

git-rebase-master

让您的功能分支随时更新来自其他人的最新作品，以便在

master

上重播您的作品。使用

rebase

而不是

merge

可以避免不必要的合并，这些合并只是簿记，并简化了历史记录

# After `git rebase master`
                  [origin/master]
A - B - C - G - H [master]
                 \
                  D1 - E1 - F1 [feature]

完成

功能

中的工作后，最后一次更新

主功能

，合并到功能分支中，然后按

主功能

。使用

git merge--no ff feature

保留feature分支的存在，以备将来考古学使用

# After `git merge --no-ff feature`
                 [origin/master]
A - B - C - G - H ------------- I [master]
                 \            /
                  D1 - E1 - F1 [feature]

# After `git push`
                                  [origin/master]
A - B - C - G - H ------------- I [master]
                 \            /
                  D1 - E1 - F1 [feature]

然后删除分支。历史的地形将保留其存在。这有助于未来的代码考古学家了解您的代码，方法是显示哪些提交作为单个功能组合在一起

                                  [origin/master]
A - B - C - G - H ------------- I [master]
                 \            /
                  D1 - E1 - F1

---

最后，如果您真的想按自己的方式执行，可以使用

git checkout--ours

来签出干净的版本。它是“我们的”，因为当您

git pull

时，您实际上是在执行

git fetch

+

git merge origin/master

<代码>母版是“我们的”，而

产地/母版

是“他们的”

---

我不建议您这样做，因为您现在必须自己手动执行合并，从而无法使用合并工具。您很可能会犯错误，导致更多冲突。

git中的常见工作流是在合并失败后调用

git mergtool

。可以使用您喜欢的任何程序调用Mergetool:

kdiff3

，

bcompare

，

p4merge

通过命令：

# After `git pull` on `master` to get other's work.
                  [origin/master]
A - B - C - G - H [master]
         \
          D - E - F [feature]

git mergetool [--tool=<tool>]. 

---

阅读有关配置的内容。

在任何

git pull

之前，您只需养成

git commit

-ing的习惯（因此，只需在树上执行

git pull

，而不必修改

git status

）这些“更好的方法”是什么？Git支持各种合并工具。@Basile Starynkevitch这在某些情况下可能很有用，但让我们假设我正在处理一个不支持的情况，因为我是。（例如，我做了一些编辑，但它的状态足够有效，可以提交，甚至在本地提交。）

git-fetch-origin-foo&&git-merge-tree$（git-merge-base-HEAD-fetch\u-HEAD）HEAD-fetch\u-HEAD

。它在大多数情况下都有效。你是否出于某种原因排除了简单地执行“git merge--abort”（需要时）的可能性？你提到的

git mergetool

解决它：我所需要做的就是运行

git config--global merge.tool/bin/false

@BCS*headdesk*FWIW，剩下的答案相当有用。然而，你花时间试图解释的东西强烈表明，你试图解决的问题与我试图解决的问题不同。你指出了做事的正确方法。我所寻找的是一种方法，当我试图做错事时，无论是由于错误还是其他原因，都能让事情更快地失败。如果我

pull

错误的分支，或者

merge

当我打算

rebase

时，我希望它在不修改文件的情况下失败。我希望它什么也不做。@BCS可能还有更好的方法来处理这些问题。也许你应该，你可能会得到更好的解决方案。我试图解决的问题是“如果我错误地管理了一个分支，它会添加一堆垃圾冲突标记并修改文件的git状态”。我想让它在我犯那种错误时拒绝做任何事情。（“干杯