如果你已经获取了更改，我最喜欢的是:

git log ...@{u}

这需要git 1.7。x我相信。@{u}符号是上游分支的“速记”，因此它比git log…origin/master更通用。

注意:如果你使用zsh和扩展的glog，你可能需要做一些类似的事情:

git log ...@\{u\}

如果您和我一样，您正在寻找等价于svn update -n的文件。下面的方法似乎可以达到目的。请注意，请确保首先进行git获取，以便您的本地回购有适当的更新进行比较。

$ git fetch origin
$ git diff --name-status origin/master
D       TableAudit/Step0_DeleteOldFiles.sh
D       TableAudit/Step1_PopulateRawTableList.sh
A       manbuild/staff_companies.sql
M       update-all-slave-dbs.sh

或者如果你想要从你的脑袋到遥控器的差异:

$ git fetch origin
$ git diff origin/master

在我看来，这个解决方案比提出“合并然后中止”的顶部解决方案更容易，更不容易出错(因此风险更小)。

我发现最适合我的解决方案是只执行合并并在发生冲突时中止它。在我看来，这种特殊的语法干净而简单。这就是下面的策略2。

然而，如果你想确保你不会弄乱你当前的分支，或者你只是没有准备好合并而不管冲突的存在，简单地创建一个新的子分支并合并它:

策略1:安全的方法——合并一个临时分支:

git checkout mybranch
git checkout -b mynew-temporary-branch
git merge some-other-branch

这样，如果您只是想看看冲突是什么，您可以简单地丢弃临时分支。您不需要麻烦地“中止”合并，并且您可以回到您的工作—只需再次签出'mybranch'，您将不会在分支中有任何合并的代码或合并冲突。

这基本上是一次演练。

策略2:当你确实想要合并时，但前提是没有冲突

git checkout mybranch
git merge some-other-branch

如果git报告冲突(且仅当存在冲突时)，你可以这样做:

git merge --abort

如果合并成功，则不能中止它(只能重置)。

如果您还没有准备好合并，请使用上面更安全的方法。

[编辑:2016年11月-我把策略1换成了策略2，因为似乎大多数人都在寻找“安全的方式”。策略2现在更多的是说明，如果合并有您还没有准备好处理的冲突，您可以简单地中止合并。请记住，如果阅读评论!］

添加到现有的答案，可以创建一个别名来显示合并之前的差异和/或日志。许多答案省略了在“预览”合并之前首先要做的取回;这是一个将这两个步骤合并为一个步骤的别名(模拟类似于mercurial的hg传入/传出)

所以，在“git log ..”，您可以在~/中添加以下内容。gitconfig:

...
[alias]
    # fetch and show what would be merged (use option "-p" to see patch)
    incoming = "!git remote update -p; git log ..@{u}"

为了对称，可以使用以下别名来显示在push之前提交和将被push的内容:

    # what would be pushed (currently committed)
    outgoing = log @{u}..

然后你可以运行“git incoming”来显示大量的更改，或者“git incoming -p”来显示补丁(即“diff”)，“git incoming -pretty=oneline”，用于简短的摘要，等等。然后你可以(选择性地)运行“git pull”来合并。(不过，因为你已经获取了，合并可以直接完成。)

同样，“git outgoing”显示了如果你要运行“git push”，将会推送什么。

Git日志..将被合并到当前分支的变更的其他分支列表。 Git差异…Otherbranchdiff从共同祖先(合并基)到将要合并的对象的头部。注意这三个点，与两个点相比，这三个点具有特殊的意义(见下文)。 gitk……上次合并后的分支的其他分支图形表示。

空字符串意味着HEAD，所以这就是为什么…而不是HEAD..otherbranch。

两点和三点对于diff和列出修订的命令(log、gitk等)的含义略有不同。对于log和其他两个点(a..b)意味着所有在b中但不是a的东西，三个点(a..b)意味着所有在a或b中只有一个的东西。但diff工作有两个修订，其中由两个点(a..b)表示的更简单的情况是a到b的简单差异，三个点(a..b)意味着共同祖先和b之间的差异(git diff $(git merge-base a b)..b)。

除了以一种丢弃的方式实际执行合并之外(参见Kasapo的回答)，似乎没有一种可靠的方式来看待这一点。

话虽如此，这里有一个稍微接近的方法:

git log TARGET_BRANCH...SOURCE_BRANCH --cherry

这很好地说明了哪些提交将进入合并。要查看diff，请添加-p。要查看文件名，可以添加——raw、——stat、——name-only、——name-status中的任意一个。

git diff TARGET_BRANCH的问题…SOURCE_BRANCH方法(参见Jan Hudec的回答)是，如果您的源分支包含交叉合并，则您将在目标分支中看到已经发生的更改的差异。