调用git fetch后如何查看更改的文件

Question

如果两个人在github和同一分支主服务器上工作相同的存储库。然后说人A将他们的变化推向主人而我作为人B，如何在调用git fetch后检查更改的文件？

如果我这样做：

git fetch
git merge master origin/master

我得到这一行：

aa@DESKTOP-KQQ0A3T MINGW64 ~/..
$ git merge master origin/master
Merge made by the 'recursive' strategy.
 src/main.js | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

我喜欢src/main.js中的差异是如何以这种方式描述的，但是这个信息只在我合并时出现，所以我的问题是，我应该使用什么命令来查看关于差异的相同信息但是在做之前合并？

Answer 1

在你想要的提取之后：

git diff ..origin/master

rholmes的回答更详细： How to check real git diff before merging from remote branch?

Answer 2

此命令可以帮助您：

git diff master:src/main.js

此主题看起来部分重复了这个问题：

git: diff between file in local repo and origin

Answer 3

在我回答之前，请快速说明一下：

git merge master origin/master

请不要这样做：您只需要git merge origin/master，而不是git merge master origin/master。 （幸运的是，当你运行它时，你 master，因此Git最终忽略了master部分。如果没有，你会看到Merge made by the octopus strategy 。）

让我们先回答这一部分：

  

我喜欢src/main.js中的差异是如何以这种方式描述的，但是这个信息只在我合并时出现，所以我的问题是，我应该使用什么命令来查看关于差异的相同信息但是在做之前合并？

要查看git merge会说什么（假设您的工作树“干净”，git status会说“无需提交”），请运行：

git diff --stat HEAD...HEAD@{upstream}

生成摘要的--stat。让我们稍微讨论git diff这里的论点;但是让我们注意（因为它很重要）这假设一个简单的，普通的单合并基础提交合并，或快速操作（这些很可能）。

  

如何在调用git fetch后检查更改的文件？

这个问题本身就显示出一些混乱（自然混乱，因为Git非常令人困惑:-)）。具体来说， git fetch并未更改任何文件。 git fetch所做的是获取新的提交。每次提交都是快照 - 所有文件的副本，就像您制作快照时一样 - 快照本身不是更改。

但与此同时，如果您查看包含git show或git log -p的快照，Git将显示更改。如果快照是快照，而不是变更集，Git如何显示更改？嗯，经过一番思考，答案是显而易见的。这就像其中一个"spot the difference" pictures / quizzes：

• 查看之前的快照。
• 然后查看此快照。
• 改变了什么？

即使提交是快照，git show也会向您显示更改集。提交有一个父提交，Git只与父{4}}或git diff进行比较，其提交的哈希为 {{ 1}} 的。 （hash~1和hash^1后缀都会退回Git图中的第一个父级。）

关于hash及其参数

~1命令非常复杂，因此它可以做的不仅仅是这个，但是对于第一个近似，它只是比较两个完整的快照。你怎么命名它们并不重要：

^1

例如，

将找到提交 - 哈希ID - git diff名称，以及git diff命名的提交，然后比较两者。输出是一组指令：这是如何更改第一次提交以使其看起来像第二次提交。

你可以写：

git diff origin/master master

如果你愿意的话。当你使用origin/master执行此类操作时，通常会看到许多提交，而不仅仅是两次提交。 master命令不同：它只是查看这两个提交。实际上，它抛弃了git diff origin/master..master 部分（当然，它们用于分隔两个名称）。

在合并时，还有另一种特殊的git log语法：git diff表示..。这就是我们上面使用的。通常，三点语法具有不同的含义; git diff将其更改为此特定的“告诉我合并会做什么”的意思，而不是。

（在完成合并之后，这不是git diff A...B在末端运行的内容，因为在合并完成后，合并基础发生了变化。并且，如果合并基础是不仅仅是单个提交，git diff $(git merge-base A B) B语法无论如何都会选择一个提交，并比较这两个提交，而git diff将默认为更复杂的策略。因此，在之后一个真正的合并完成，Git可以运行git merge，这实际上就是它的作用。对于快进的非真正合并的“合并”，Git可以运行git diff A...B。）< / p>

有关三点表示法的正常和特殊Git-diff-only含义的更多信息，请参阅the gitrevisions documentation和the git diff documentation。

Answer 4

如果您知道自己触摸了哪些文件，请快速查看：

git log —name-status HEAD..origin/master

这将让您快速了解您的同事提交以及在该提交中修改了哪些文件。如果您注意到其中一个文件也是您正在处理的文件，那么您可以继续并对文件进行区分：

git diff master:src/main.js