为什么git总是会在出现合并冲突的情况下显示2个分支 - 日志中的父1和父2，并且在执行git pull之后推送更改后解决这些冲突？
在合并冲突的情况下，它是如何工作的？
由于 阿希什
答案 0 :(得分：0)
如果git在合并期间发现冲突，它将列出错误消息后出现冲突的所有文件。您还可以通过执行＆＃39; git status＆＃39;。
来检查哪些文件存在合并冲突要在文件中找到冲突， ＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt;＆lt ;:这表示出现合并冲突的行的开始
在下面找到一些有用的命令。
git diff
帮助查找存储库/文件状态之间差异的命令。用于预测和防止合并冲突。
git diff origin/master <fileName>
查找fileName的当前索引（HEAD）与中央存储库（origin / msater）中的内容之间的差异
来自origin / master的更改标有+，而本地存储库（HEAD）中的更改标有 - 。
git status
该命令提供了已修改且在合并时发生冲突的所有文件的概述。
答案 1 :(得分：0)
合并提交 是一个包含两个 1 父项的提交，无论是否有要解决的冲突。 Git中的一个混乱点是，并非所有git merge 操作都会导致合并提交。
在任何情况下，当您进行合并提交时，会留下Git稍后在git log期间显示的路径，或者稍后会看到，以便进行后续合并操作。这告诉Git，在合并点之外，结果是做出合并的人的意图。如果存在冲突 - 或者有时，即使没有 - 合并结果不与简单的＆＃34完全相同;采取两组更改＆＃34;。
当你运行git merge theirbranch时，Git：
theirbranch 这个基于合并的提交是你的分支及其分支最后一次＆＃34;，即由于没有分歧或已经合并而最后同步的点。既然Git知道它是什么，并假设满足其他一些条件， 2 Git继续：
当您和他们对同一文件的相同部分进行不同的更改时，会出现合并冲突。在这种情况下，Git会将两个更改放入工作树中的文件中，并在进行新提交之前停止。然后，您的工作是修复文件的工作树版本git add结果，然后运行git commit完成合并。正如您所看到的，冲突的部分--Git无法自行合并的东西 - 被冲突标记所包围。 Git 可能会在同一个文件中自行解决其他更改，具体取决于您的操作和执行的操作。
如果您对某些文件的某些部分进行了相同的更改，Git只会获取该更改的一个副本！例如，如果您删除了带有拼写错误的单词的行，并且拼写正确拼写单词，Git不会尝试删除原始行两次，也不会将两个副本放入固定线路。
如果一切顺利 - 如果没有合并冲突 - git merge将git add所有文件并为您运行git commit。您可以通过向命令添加--no-commit来阻止最后一步。在这种情况下，即使没有合并冲突，Git也会停止，这允许您在提交合并之前测试并在必要时更改合并结果。这是另一种使合并与仅仅＃34;组合变化＆＃34;。
如果您已经开始合并但尚未完成（由于--no-commit和/或合并冲突），您可以完全使用git merge --abort中止合并。这将删除所有部分分辨率，并返回到开始合并之前的状态。
但是，在所有真正合并的情况下，最后一次提交，如果你创建一个，则有两个父提交。第一个父项是您启动时HEAD的提交。第二个父级是 theirbranch 的提示。新的提交会照常添加到当前分支。
1 从技术上讲，合并是指具有两个或更多父项的任何提交。三个或更多个父合并提交称为章鱼合并。他们不做任何你能做普通合并的事情，所以他们主要是为了炫耀你的Git-fu。 :-)（更严重的是，他们要同时将几个分支捆绑在一起，以表明目标是占用所有这些分支。）
2 如果合并基础是 HEAD提交，则无需合并。如果合并基础是另一个提示提交，则合并可以作为＆＃34;快进＆＃34;来完成。如果有没有合并基础，较新版本的Git会告诉您历史记录不相关（旧版本与空树合并，这至少有点奇怪，但如果您使用，仍然允许--allow-unrelated-histories）。
同时，git merge也有--squash选项，告诉它运行合并机器 - 两个差异和组合 - 但是要使新提交有只有一个父级，而不是两个。生成的提交（您必须手动进行）不是合并提交，稍后的Git操作会认为两个分支的历史记录不组合在一起。这将使Git做更多的工作，并且随着时间的推移，分支可能变得非常难以合并，没有真正的合并提交。