当您从远程repo运行git pull时，您将看到更新的所有文件和更改的行数的列表，以及插入/删除的大致比率。您还会看到任何已创建、重命名、删除和模式更改的文件。例如：
Updating 5524541..cff1e7a
Fast-forward
.gitignore | 4 +-
.vscode/settings.json | 7 ++
README.md | 40 ++++++-
clean.sh => dev_scripts/clean.sh | 0
dev_scripts/main.sh | 2 +-
... many more files here ...
41 files changed, 1044 insertions(+), 502 deletions(-)
create mode 100644 .vscode/settings.json
rename clean.sh => dev_scripts/clean.sh (100%)
delete mode 100644 dev_scripts/test_old.py
create mode 100644 postinstall/2.0.7_00_fix_missing_models.py
create mode 100644 test/csv_test.py
有没有一种方法可以通过指定本地回购的开始和结束提交来获得类似的输出？我基本上想要与git pull快进输出相同的输出，但没有实际执行任何操作，只是显示如果我的本地回购处于提交a，远程回购处于提交B，并且我进行了拉操作(即使两个提交都已经在本地回购中)，将发生什么。或者，也许更简洁地说，我想看到一个总结列表，列出如果我从提交a开始并签出提交B会发生什么。
我知道git diff，它基本上执行所需的功能(向我展示两次提交之间的变化)，但它打印出了两次提交间的全部差异(我相信它以适合patch的形式出现？)，而我只是在寻找类似快进报告的摘要报告。
正如KateYoak在评论中建议的那样，您需要git diff --stat --summary。棘手的部分是找到正确的提交(或散列ID)作为这个git diff的两个输入。然而，它们就在你的屏幕上：
Updating 5524541..cff1e7a
您也可以在HEAD@{1}和HEAD(或HEAD@{0})中找到它们一段时间，尽管最终这些数字会增加，使它们在HEAD@{2}和HEAD@{1}中，然后在HEAD@{3}和HEAD@{2}中，依此类推。您可以对您所在的分支使用reflog，因为这些数字通常会缓慢增加。例如，如果您在分支dev上，这些将是dev@{1}和dev@{0}等。
(请注意，这两个提交哈希ID不太可能再次出现在其他人身上，因此从这个答案中拯救它们是没有意义的。因为它们是缩短的哈希ID，所以它们比任何一个完整哈希ID的1-in-2160机会都更有可能，但它们仍然非常不可能。)
为什么这样做
运行
git pull时。。。
。。。您实际上正在运行git fetch，然后运行第二个Git命令。在您的案例中，第二个Git命令是git merge。
git fetch操作从其他Git存储库中获得了一些新的提交。在这种情况下：
Updating 5524541..cff1e7a
它获得了一些以提交cff1e7a结束的一系列提交。
此时，连接到某个分支名称的HEAD发现您的当前提交是5524541。也就是说，如果您在分支dev上，名称dev意味着5524541。
新提交的CCD_ 27是"；严格领先于"；提交5524541，因此当您的git pull运行git merge时(允许快进操作而不是合并)，您的git merge执行快进操作，更改当前分支名称以使其引用cff1e7a1这一切都很正常，但它移动得很快，你可能没有看到它发生。
最后，无论git merge做了什么，Git都会从旧的提交(即5524541)到新的提交(cff1e7a)生成一个git diff --stat --summary。这就是你看到的输出。因此，如果您想重现该输出，请运行git diff --stat --summary 5524541 cff1e7a。
请注意，不需要使用双点语法：
git diff --stat --summary 5524541 cff1e7a
和：
git diff --stat --summary 5524541..cff1e7a
做完全相同的事情。键入一个空格比键入两个点更容易，而且考虑到git diff的工作方式，一个空格版本比两个点版本更符合逻辑，所以我推荐它。
如果您愿意，您可以只使用--stat或--summary中的一个。--stat部分包括
41 files changed, 1044 insertions(+), 502 deletions(-)
和--summary部分是其余部分。
1不是所有的合并都可以是快进的，但如果你喜欢的话，所有的快进都可以作为真正的合并来完成。当要存储在某个引用中的新值是现在存储在该引用中的哈希ID的后代时，就会发生快进。分支名称是一种特殊的引用形式，因此分支名称可以是快速转发的。默认情况下允许git merge进行快进。因此，当git pull运行git merge时，快进操作是常见的。
尽管这是一个意见问题，但我们中的一些人(包括我自己)认为，在使用git pull时，只有的快进操作才是真正合适的。所以这是一件好事。当git pull导致真正的合并时，它会产生一些人所说的狐步合并，这在某种意义上通常是"；向后"；。另请参阅GIT：如何在我的'；master'；树枝在某种程度上，这是次要的，但狐步合并仍然不好。