想象一个非常简单的textdocument（text.txt），其中的内容只是字母'ab'。此文件已在规范（远程）存储库中签入。两个人有一个本地关闭这个存储库，因此这个文件，并开始编辑它。 Dan将内容更改为'aB'（注意大写B），John将其版本编辑为'abc'。 Dan做了一次提交并将其推送到规范存储库。稍后John做一个本地提交并将更改推送到远程。当John推送他的仓库时会发生什么（消息）？当Dan将文本更改为'aB'并将John更改为'abc'时会发生什么？
会有合并冲突
没有冲突。约翰的推动只会被拒绝，因为他试图推动的承诺不是远程分支的直接后裔。
如果John想要推送他的提交，他必须首先将它与远程分支头部的提交合并或者在提交之上回扣提交。在这一点上，他将不得不选择如何解决文本文件中产生的冲突。
这取决于John推动时使用的标志。
默认情况下，它将无法推送，因为远程分支头（Dan的提交）不是John的修订版的祖先。
使用-f或--force，它将简单地覆盖Dan与John的变化，从而有效地取消Dan的推送 - 如果服务器设置为允许至少强制推送。许多git服务器会拒绝这样做。
一般来说，“正确”的做法是约翰尝试正常推送。他会看到我提到的错误，并知道其他人已经做出了改变。然后，他会做一个git pull来检索丹的变化，并将其与他自己的变化合并。拉将尝试合并，导致您的文本文件发生冲突，并将其留给John修复。在John解决冲突后（可能通过使文件包含'aBc'，然后使用git add text.txt; git commit让git知道），他的本地存储库将包含一个'合并提交'，该合并提交被标记为包含这两个更改。然后他可以将其推送到服务器，而不会有其他问题。
更确切地说，合并提交将每个分支的提示作为父母;提交本身不包含这两个更改，而是包含冲突的解决方案。 – Cascabel 2010-06-22 19:47:29