我可能迟到了，但这件事已经困扰我太久了。 根据我的经验，我更希望看到哪些更改正在等待，而不是更新我的工作副本并处理这些更改。

这是~/。gitconfig文件:

[alias]
    diffpull = !git fetch && git diff HEAD..@{u}

它获取当前分支，然后在工作副本和这个获取的分支之间做一个差异。因此，您应该只看到git pull带来的更改。

我使用这两个命令，就可以看到要更改的文件。

首先执行git获取，它给出如下输出(输出的一部分): .．. 72年f8433 . .C8af041 develop -> origin/develop .．.

这个操作给了我们两个提交id，第一个是旧的，第二个是新的。

然后使用git diff比较这两个提交 Git差异72f8433..C8af041 | grep“diff—git”

这个命令将列出要更新的文件:

diff --git a/app/controller/xxxx.php b/app/controller/xxxx.php
diff --git a/app/view/yyyy.php b/app/view/yyyy.php

例如app/controller/xxxx.php和app/view/yyyy.php将被更新。

使用git diff比较两次提交会打印所有更新过的文件 更改了行，但是使用grep，它只搜索并获得行 从输出中包含diff——git。

在做一个git取回之后，做一个git log HEAD..Origin /master显示您的最后一次公共提交和原点的主分支之间的日志条目。要显示差异，使用git log -p HEAD..origin/master显示每个补丁，或者git diff HEAD…原点/母点(三个点而不是两个点)显示单个差异。

通常不需要撤销获取，因为执行获取只更新远程分支，而不更新您的任何分支。如果您不准备在所有远程提交中执行拉取和合并操作，您可以使用git选择性地只接受您想要的特定远程提交。稍后，当您准备好获取所有内容时，git拉取将在其余提交中合并。

更新:我不完全确定为什么你要避免使用git获取。所有git获取所做的是更新远程分支的本地副本。这个本地副本与您的任何分支都没有任何关系，也与未提交的本地更改没有任何关系。我听说有人在cron作业中运行git fetch，因为它非常安全。(不过，我通常不建议这样做。)

您可以从远程回购中获取，查看差异，然后拉取或合并。

这是一个名为origin的远程回购和一个名为master的分支跟踪远程分支origin/master的示例:

git checkout master                                                  
git fetch                                        
git diff origin/master
git pull --rebase origin master

13年后，你现在在“git维护”中有一个预取任务

The prefetch task updates the object directory with the latest objects from all registered remotes. For each remote, a git fetch command is run. The refmap is custom to avoid updating local or remote branches (those in refs/heads or refs/remotes). Instead, the remote refs are stored in refs/prefetch/<remote>/. Also, tags are not updated. This is done to avoid disrupting the remote-tracking branches. The end users expect these refs to stay unmoved unless they initiate a fetch. With prefetch task, however, the objects necessary to complete a later real fetch would already be obtained, so the real fetch would go faster. In the ideal case, it will just become an update to a bunch of remote-tracking branches without any object transfer.

从Git 2.32 (Q2 2021)开始，你也可以做一个Git预取，同样不修改你上次的读取状态。

参见Derrick Stolee (derrickstolee)提交的commit 32f6788、commit cfd781e、commit 2e03115(2021年4月16日)和commit a039a1f(2021年4月06日)。 (由Junio C Hamano - gitster -在commit d250f90中合并，2021年4月30日)

取:添加——预取选项 资助人:Tom Saeger 资助人:Ramsay Jones 署名:Derrick Stolee

The --prefetch option will be used by the 'prefetch' maintenance task instead of sending refspecs explicitly across the command-line. The intention is to modify the refspec to place all results in refs/prefetch/ instead of anywhere else. Create helper method filter_prefetch_refspec() to modify a given refspec to fit the rules expected of the prefetch task: Negative refspecs are preserved. Refspecs without a destination are removed. Refspecs whose source starts with "refs/tags/" are removed. Other refspecs are placed within "refs/prefetch/". Finally, we add the 'force' option to ensure that prefetch refs are replaced as necessary. There are some interesting cases that are worth testing. An earlier version of this change dropped the "i--" from the loop that deletes a refspec item and shifts the remaining entries down. This allowed some refspecs to not be modified. The subtle part about the first --prefetch test is that the refs/tags/* refspec appears directly before the refs/heads/bogus/* refspec. Without that "i--", this ordering would remove the "refs/tags/*" refspec and leave the last one unmodified, placing the result in "refs/heads/*". It is possible to have an empty refspec. This is typically the case for remotes other than the origin, where users want to fetch a specific tag or branch. To correctly test this case, we need to further remove the upstream remote for the local branch. Thus, we are testing a refspec that will be deleted, leaving nothing to fetch.

Fetch-options现在包含在它的手册页中:

——预取 修改已配置的refspec以将所有引用放入 refs /预取的名称空间。

我创建了一个自定义的git别名来为我做这件事:

alias.changes=!git log --name-status HEAD..

你可以这样做:

$git fetch
$git changes origin

这将为您提供一个在进行合并之前预览更改的好方法。