完成拉动（来自远程原点）后，git抛出我的默认（vi）编辑器，要求我解释合并。我假设这需要覆盖git执行的自动合并，因为否则，拉动只会进入下一个命令提示符。
我想看看哪些文件是自动合并的，所以我可以看到其他人在做什么，我也在努力。有没有这样做的命令，还是我需要查看git的日志？
的问题不完全相同答案 0 :(得分：1)
与链接的问题一样，您必须通过“自动合并”来定义您的意思。 （和往常一样，我们应该首先定义git pull：它实际上只是git fetch，以获取您在自己的Git存储库中没有的任何远程提交，然后是{{1 ，将当前分支 - 无论是什么 - 与git merge刚刚找到的其他Git的分支提示进行合并。）
值得考虑合并过程 - 我想称之为合并为动词，在这里你告诉Git合并两个特定的提交，git fetch和--ours ，或左右，或本地和远程，或简称 L 和 R 。至少对于普通命令， L （左/本地/ --theirs）提交始终是--ours（当前）提交。 R 提交是您选择的，或者HEAD，根据从远程Git获取的内容来获取拉取代码。 git pull命令并不总是这样做！有时，git merge可以完全跳过合并为动词的过程部分，执行Git称之为快进的行为。但在这种情况下，你永远不会让编辑器会话要求你解释合并，所以在这种情况下，你得到一个真正的合并。
无论如何，合并过程采用这两个提交， L 和 R 提交，并从存储库中的提交图中找到哪个提交是合并这两个提交的基础。使用git merge - 或者像有人说的那样，“来自A DOG的帮助”， A ll D ecorate O neline G raph，git log --graph - 您可以让Git为您绘制存储库中的内容的ASCII艺术图表，并尝试从中读取图表。在某些情况下，它非常清楚;在其他人中，这很难说。我喜欢水平绘制StackOverflow帖子的图表：
git log --all --decorate --oneline --graph在这种情况下，仅在您自己的分支上的提交位于顶部;只有 o--L <-- somebranch (HEAD)
/
...--o--B
\
o--R <-- origin/somebranch
版本的分支的提交，由origin/步骤引入，位于底部;并且两者上的提交都位于中间。最后一次提交“最接近” L 和 R ，是合并基础提交 B 。
你不必自己找到 B -Git计算它，你可以通过运行找出Git计算的内容：
git fetch其中 git merge-base --all HEAD <other-commit>
是标识提交 R 的内容（如哈希ID或<other-commit>名称）。如果打印出多个提交哈希ID，我们在这里遇到了一些麻烦。 Git 处理此问题，但我们现在必须考虑origin/somebranch和-s recursive之间的区别。但这很少见，所以我们可以忽略它并假装它永远不会发生。 1 ： - ）
无论如何，既然我们有三个提交ID，我们现在可以做Git会做的事情：
-s resolve 我们在git diff --find-renames B L中发生了什么变化？
--ours 他们在git diff --find-renames B R中发生了哪些变化？
所有这些差异的结果告诉我们我们和他们更改，重命名，删除或添加了哪些文件，以及行更改了哪些文件。 Git使用这种信息 - 在内部以更优化的方式获得，但具有相同的效果 - 进行合并。
不幸的是，如果一切顺利，当您在编辑器会话中尝试描述合并时，上述所有信息都已消失。你剩下的就是索引（临时区域）和工作树中的任何东西，它只是合并的结果。此外，Git不会告诉您合并基础 B 的哈希ID。如果你至少有这个，你可以重新运行两个--theirs命令并选择它们。
如果你认为合并是合适的话，如果你完全避免git diff，然后自己做git pull，然后检查一下事情和那么 git fetch你有更多的工作空间。您可以找出哪些提交是 B 的基础，并运行您自己的快速git merge（例如，可能使用git diff查看哪些文件受到影响以及如何创建，修改，删除和/或重命名。现在你已经非常了解git diff --find-renames --name-status在运行git merge之前会做什么，所以当你最终进入编辑器时，你知道该怎么做写！
1 如果你想出于某些奇怪的原因，实现它的方法是做“纵横交错合并”：将一个分支合并到另一个分支，然后在相反的方向。你必须强制Git不要进行快进而不是真正的合并才能完成第二次合并。一旦你完成了这对合并，两个合并将在以后与两个分支提示“同样接近”。