现在特性分支上已合并好了贡献者的代码，是时候决断取舍了。本节将回顾一些之前学过的命令，以看清将要合并到主干的是哪些代码，从而理解它们到底做了些什么，是否真的要并入。

一般我们会先看下，特性分支上都有哪些新增的提交。比如在 contrib 特性分支上打了两个补丁，仅查看这两个补丁的提交信息，可以用 --not 选项指定要屏蔽的分支 master，这样就会剔除重复的提交历史：

$ git log contrib --not master
    commit 5b6235bd297351589efc4d73316f0a68d484f118Author: Scott Chacon <schacon@gmail.com>Date: Fri Oct 24 09:53:59 2008 -0700
    seeing if this helps the gem
    commit 7482e0d16d04bea79d0dba8988cc78df655f16a0Author: Scott Chacon <schacon@gmail.com>Date: Mon Oct 22 19:38:36 2008 -0700
    updated the gemspec to hopefully work better

还可以查看每次提交的具体修改。请牢记，在 git log 后加 -p 选项将展示每次提交的内容差异。

如果想看当前分支同其他分支合并时的完整内容差异，有个小窍门：

$ git diff master

虽然能得到差异内容，但请记住，结果有可能和我们的预期不同。一旦主干 master 在特性分支创建之后有所修改，那么通过 diff 命令来比较的，是最新主干上的提交快照。显然，这不是我们所要的。比方在 master 分支中某个文件里添了一行，然后运行上面的命令，简单的比较最新快照所得到的结论只能是，特性分支中删除了这一行。

这个很好理解：如果 master 是特性分支的直接祖先，不会产生任何问题；如果它们的提交历史在不同的分叉上，那么产生的内容差异，看起来就像是增加了特性分支上的新代码，同时删除了 master 分支上的新代码。

实际上我们真正想要看的，是新加入到特性分支的代码，也就是合并时会并入主干的代码。所以，准确地讲，我们应该比较特性分支和它同 master 分支的共同祖先之间的差异。

我们可以手工定位它们的共同祖先，然后与之比较：

$ git merge-base contrib master36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
    $ git diff 36c7db

但这么做很麻烦，所以 Git 提供了便捷的 ... 语法。对于 diff 命令，可以把 ... 加在原始分支(拥有共同祖先)和当前分支之间：

$ git diff master...contrib

现在看到的，就是实际将要引入的新代码。这是一个非常有用的命令，应该牢记。

！爆享折扣！

▼▼▼ 原价129， 今日拼团仅需 ¥99！ 新人专享首单限时优惠 ¥19.9！！！ 但！ 仅限前100个名额！ ???