Git 如何显示从pull自动合并的文件？

在完成一次拉取（从远程源）之后，git抛出了我的默认（vi）编辑器，要求我解释合并。我假设这是覆盖git执行的自动合并所必需的，因为否则，pull只会进入下一个命令提示符

我想看看哪些文件是自动合并的，这样我就可以看到其他人在做什么，我也在做什么。有没有这样的命令，或者我需要查看git的日志

---

这个问题与链接问题不同，您必须定义“自动合并”的含义。（和往常一样，我们应该从定义

git pull

开始：它实际上只是

git fetch

，从远程获取您自己的git存储库中还没有的任何提交，然后是

git merge

，将您当前的分支与另一个git的分支tip commit合并，

git fetch

）>刚找到。）

值得考虑的是合并过程，我喜欢将其称为merge作为动词，在这个过程中，您告诉Git合并两个特定的提交，即

--我们的

和

--他们的

，或左和右，或本地和远程，或简称L和R。至少对于普通命令而言，L（左/本地--我们的）提交是，始终是

头

（当前）提交。R提交是您选择的，或者使用

git pull

，根据从远程git获取的内容选择pull代码。

git merge

命令并不总是这样做！有时候，

gitmerge

可以完全跳过merge-as-a-verb过程部分，执行git称之为快进的操作。但是在这种情况下，您永远不会得到编辑器会话要求您解释合并，因此在这种情况下，您将得到一个真正的合并

无论如何，合并过程接受这两个提交，即L和R提交，并从存储库中的提交图中查找哪一个提交是这两个提交的合并基础。使用

git log--graph

-或者像有人说的那样，“狗的帮助”AllDecorateOnelineGraph，

git log--all--decoration--oneline--graph

-你可以让git为你的存储库绘制一张ASCII艺术图表，然后试着从那里读出图表。在某些情况下，这是相当清楚的；在其他国家，这很难说。我喜欢水平绘制StackOverflow帖子的图表：

          o--L   <-- somebranch (HEAD)
         /
...--o--B
         \
          o--R   <-- origin/somebranch

其中，

是标识提交R的东西（如哈希ID或

源代码/somebranch

名称）。如果这打印出多个提交哈希ID，我们在这里会遇到一些麻烦。Git确实可以处理这个问题，但是我们现在必须研究

-s recursive

和

-s resolve

之间的区别。但这很少见，所以我们可以忽略它，假装它从未发生过。1:-）

总之，现在我们有了所有三个提交ID，现在我们可以做Git将要做的事情：

git diff--find重命名BL

我们在

--ours

中更改了什么？

git diff--find重命名br

他们在

--他们的

中更改了什么

所有这些差异的结果告诉我们我们和他们更改、重命名、删除或添加了哪些文件，以及更改了哪些行。Git在内部使用以更优化的方式获得的信息，但在进行合并时具有相同的效果

不幸的是，如果一切顺利，当您在编辑器会话中试图描述合并时，上面的所有信息都消失了。剩下的是索引（临时区域）和工作树中的内容，这只是合并的结果。此外，Git不会告诉您合并基B的哈希ID。如果您至少有这个ID，您可以重新运行这两个

Git diff

命令，然后选择它们

如果您完全避免使用

git-pull

，并且自己执行

git-fetch

，然后检查事物，然后进行

git-merge

，如果您认为合并是合适的，这会给您更多的工作空间。您可以确定什么是提交（commit）是基本B，并运行自己的quick

git diff

s（例如，可以使用

git diff--find renames--name status

，查看哪些文件受到影响，以及如何创建、修改、删除和/或重命名）。现在，在运行

git merge

之前，您将非常清楚地了解git merge将执行什么操作，这样当您进入编辑器时，您就知道该编写什么了

---

1如果你出于某种奇怪的原因想这样做，那么实现的方法就是“交叉合并”：将一个分支合并到另一个分支，然后以相反的方向进行相同的合并。您必须强制Git不要进行快进的非真正的合并，这样才能进行第二次合并。一旦有了这对合并，两个合并将在稍后与两个分支提示“同等接近”

git merge-base --all HEAD <other-commit>