标签 ：github

引言

本文主要讲解Git的相关命令和基本用法，是根据Git常用命令学习手册这篇博文进行整理的。主要目的是为了以后更好的学习Git以及快速查阅相应的Git命令做准备的。另外本文只是简单介绍相关的Git命令。详细命令请查阅《Pro Git》

一、获取与创建项目

1、Git使用前的配置
为了在命令界面可以方便使用复制和粘贴（用左键选取要复制的，点右键直接就可以复制，粘贴时只需点一下右键。）设置方法：Git Bash快捷图标（桌面图标）右键属性-选项，把快速编辑模式勾上就可以，如下图：

Git Bash配置图

设置本地默认开发路径

如果设置了，就不用每次打开Git再cd打开目录了。方法：右键Git Bash快捷图标（桌面图标）属性，找到快捷方式-起始位置，把你的项目地址放在这里就可以了。如下图：

Git本地默认开发路径设置

配置本地用户和邮箱

用户名邮箱作用 : 我们需要设置一个用户名 和 邮箱, 这是用来上传本地仓库到GitHub中, 在GitHub中显示代码上传者;
使用命令 :

git config --global user.name "lx198911m10d"
git config --global user.email "branden123@163.com"

到此Git客户端已安装及GitHub配置完成，现在可以从GitHub传输代码了。

git init 将一个目录初始化为Git仓库

在目录中执行git init,就可以创建一个Git仓库了。代码实例如下

$ git init
Initialized empty Git repository in C:\github\resource
#在C:\github\resource目录初始化空Git仓库完毕

git clone 复制一个Git仓库

git clone [url]这条命令主要用来从网上复制其他人的项目代码。

example:
    $ git clone git://github.com/schacon/simplegit.git

上述操作以后就可以将相应的项目的全部记录保存到本地git仓库中。同时拷贝了该项目的主分支。使你能够查看代码，或编辑、修改。进到该目录中，你会看到 .git 子目录。

二、基本快照

git add 添加文件到缓存

使用git add添加需要追踪的新文件和待提交的更改。使用git add .和git add *提交项目目录中所有的更改到缓存。
使用git status输出相对繁琐。使用git status -s查看项目文件的状态。
文件前面的??表示新文件没有存到缓存中。A表示相应的文件已经在缓存中。AM表示相应的文件在缓存中但文件改动没有存到缓存中。

git diff 显示已写入缓存与已修改但尚未写入缓存的改动的区别

git diff
如果没有其他参数，git diff会以规范化的diff格式显示自从你上次提交快照之后尚未缓存的所有改动。
git diff --cached显示有哪些内容已经写入缓存了。也就是说，此命令显示的是接下来要写入快照的内容。
git diff HEAD查看已缓存的与为缓存的所有改动查看工作目录与上一次提交的更新的区别，无视缓存。
git diff --stat与git status相比详细一点，与git diff相比显示的是更改的摘要并不是全文。

git commit 记录缓存内容的快照

现在你使用git add命令将想要快照的内容写入了缓存， 执行git commit就将它实际存储快照了。 Git 为你的每一个提交都记录你的名字与电子邮箱地址，所以第一步是告诉 Git 这些都是啥。
在执行git commit命令时，一般直接执行git commit -m 'txt'txt用来提交相关的注释。
命令git commit -a直接将项目文件中的所有改动提交到项目中，无需执行git add命令，但是如果你在项目中添加了新的文件，这时你仍然需要执行git add命令，将新文件添加到项目中。

git reset HEAD 取消缓存已缓存的内容

简而言之，执行 git reset HEAD 以取消之前git add添加，但不希望包含在下一提交快照中的缓存。

git rm 将文件从缓存区移除

git rm会将条目从缓存区中移除。这与git reset HEAD将条目取消缓存是有区别的。 “取消缓存”的意思就是将缓存区恢复为我们做出修改之前的样子。 在另一方面，git rm则将该文件彻底从缓存区踢出，因此它不再下一个提交快照之内，进而有效地删除它。
默认情况下，git rm file会将文件从缓存区和你的硬盘中（工作目录）删除。 如果要在工作目录中留着该文件，可以使用git rm --cached
简而言之， 执行git rm来删除 Git 追踪的文件。它还会删除你的工作目录中的相应文件。

三、分支与合并

git branch 列出、创建与管理工作上下文 git check 切换到新的分支上下文

• git branch 列出分支
• git branch （branchname）创建新的分支。
• git checkout -b (branchname)创建新分支，并立即切换到它。
• git branch -d (branchname)删除分支

git merge 将分支合并到你的当前分支

简而言之 使用git merge (分支名字)将另一个分支并入当前的分支中去。 Git 会自动以最佳方式将两个不同快照中独特的工作合并到一个新快照中去。

git log 显示一个分支中提交的更改记录

当你使用git commit命令提交相应的缓存内容时，提交到快照的信息都将被存储起来。除了文件详单、提交消息和提交者的信息，Git 还保存了你的此次提交所基于的快照。 也就是，假如你克隆了一个项目，你是在什么快照的基础上做的修改而得到新保存的快照的？ 这有益于为项目进程提供上下文，使 Git 能够弄明白谁做了什么改动。 如果 Git 有你的快照所基于的快照的话，它就能自动判断你都改变了什么。而新提交所基于的提交，被称作新提交的“父亲”。

某分支的按时间排序的“父亲”列表，当你在该分支时，可以执行git log以查看。
git log --oneline可以查看历史记录的紧凑简洁版本。
git log --oneline --graph查看历史中什么时候出现了分支、合并。

git tag给历史记录中的某一个重要的点打上标签,打上永久标签

如果你达到一个重要的阶段，并希望永远记住那个特别的提交快照，你可以使用git tag给它打上标签。
git log -a v1.0为当前项目版本打上v1.0标签
git log --decorate --graph查看我们给项目打的标签。
不过我们并不需要给当前提交打标签。如果我们忘了给某个提交打标签，又将它发布了，我们可以给它追加标签。 在相同的命令末尾加上提交的 SHA。（SHA就是git tag --online --decorate --graph命令每个项目前面 的数字字母序列）

四、分享与项目更新

当你需要将自己的项目放到一个能够与其他开发者链接的服务器上时，需要使用本章的内容。

git remote 罗列、添加和删除远端仓库别名

• git remote 列出远端仓库别名
• git remote add [alias] [url]为你的项目添加一个新的远端仓库

例如，假设我们想要与整个世界分享我们的 Hello World 程序。 我们可以在一台服务器上创建一个新仓库（我以 GitHub 为例子）。 它应该会给你一个链接，在这里就是“git@github.com:schacon/hw.git”(github在新项目中有提供)。

• git remote rm [alias]删除现存的某个别名

git fetch从远端仓库下载新分支与数据 git pull从远端仓库提取数据并尝试合并到当前分支。

Git 有两个命令用来从某一远端仓库更新。git fetch会使你与另一仓库同步，提取你本地所没有的数据，为你在同步时的该远端的每一分支提供书签。 这些分支被叫做“远端分支”，除了 Git 不允许你检出（切换到该分支）之外，跟本地分支没区别 —— 你可以将它们合并到当前分支，与其他分支作比较差异，查看那些分支的历史日志，等等。同步之后你就可以在本地操作这些。

第二个会从远端服务器提取新数据的命令是git pull。 基本上，该命令就是在 git fetch 之后紧接着git merge远端分支到你所在的任意分支。 我个人不太喜欢这命令 —— 我更喜欢fetch 和 merge 分开来做。少点魔法，少点问题。 不过，如果你喜欢这主意，你可以看一下git pull的 官方文档。

假设你配置好了一个远端，并且你想要提取更新，你可以首先执行 git fetch [alias] 告诉 Git 去获取它有你没有的数据，然后你可以执行 git merge [alias]/[branch] 以将服务器上的任何更新（假设有人这时候推送到服务器了）合并到你的当前分支。 那么，如果我是与两三个其他人合作 Hello World 项目，并且想要将我最近连接之后的所有改动拿过来，我可以这么做：

$ git fetch github
    remote: Counting objects: 4006, done.
    remote: Compressing objects: 100% (1322/1322), done.
    remote: Total 2783 (delta 1526), reused 2587 (delta 1387)
    Receiving objects: 100% (2783/2783), 1.23 MiB | 10 KiB/s, done.
    Resolving deltas: 100% (1526/1526), completed with 387 local       objects.
    From github.com:schacon/hw
    8e29b09..c7c5a10  master     -> github/master
    0709fdc..d4ccf73  c-langs    -> github/c-langs
    6684f82..ae06d2b  java       -> github/java
    * [new branch]      ada        -> github/ada
    * [new branch]      lisp       -> github/lisp

可以看到自从上一次与远端仓库同步以后，又新赠或更新了五个分支。 “ada”与“lisp”分支是新的，而“master”、“clang”与“Java”分支则被更新了。 在此例中，我的团队在合并入主分支之前，将提议的更新推送到远端分支以审核。
你可以看到 Git 做的映射。远端仓库的主分支成为了本地的一个叫做“github/master”的分支。 这样我就可以执行git merge github/master将远端的主分支和并入我的本地主分支。 或者，我可以git log github/master ^master看看该分支上的新提交。 如果你的远端仓库叫做“origin”，那远端主分支就会叫做origin/master。几乎所有能在本地分支上执行的命令都可以在远端分支上用。
如果你有多个远端仓库，你可以执行git fetch [alias]提取特定的远端仓库， 或者执行git fetch --all告诉 Git 同步所有的远端仓库。

git push 推送你的新分支与数据到某个远端仓库

想要与他人分享你牛鼻的提交，你需要将改动推送到远端仓库。 执行git push [alias] [branch]，就会将你的 [branch] 分支推送成为 [alias] 远端上的 [branch] 分支。 让我们试试推送我们的主分支到先前添加的“github”远端仓库上去。

$ git push github master
Counting objects: 25, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (25/25), done.
Writing objects: 100% (25/25), 2.43 KiB, done.
Total 25 (delta 4), reused 0 (delta 0)
To git@github.com:schacon/hw.git
 * [new branch]      master -> master

挺简单。现在如果有人从该仓库克隆，他会得到我提交的完完全全的一份历史记录了。
如果有个像之前创建的“erlang”分支那样的主题分支，想只分享这个，该怎么办呢？你可以相应的只推送该分支。

$ git push github erlang
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 652 bytes, done.
Total 6 (delta 1), reused 0 (delta 0)
To git@github.com:schacon/hw.git
 * [new branch]      erlang -> erlang

现在当人们从该仓库克隆时，他们就会得到一个“erlang”分支以查阅、合并。 用这种方式，你可以推送任何分支到任何你有写权限的仓库。 如果你的分支已经在该仓库中了，它会试着去更新，如果它不再，Git 会把它加上。
最后一个当你推送到远端分支时会碰到的主要问题是，其他人在此期间也推送了的情况。 如果你和另一个开发者同时克隆了，又都有提交，那么当她推送后你也想推送时，默认情况下 Git 不会让你覆盖她的改动。 相反的，它会在你试图推送的分支上执行git log，确定它能够在你的推送分支的历史记录中看到服务器分支的当前进度。 如果它在在你的历史记录中看不到，它就会下结论说你过时了，并打回你的推送。 你需要正式提取、合并，然后再次推送 —— 以确定你把她的改动也考虑在内了。
当你试图推送到某个以被更新的远端分支时，会出现下面这种情况：

$ git push github master
To git@github.com:schacon/hw.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:schacon/hw.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

你可以修正这个问题。执行 git fetch github; git merge github/master，然后再推送
简而言之 执行 git push [alias] [branch] 将你的本地改动推送到远端仓库。 如果可以的话，它会依据你的 [branch] 的样子，推送到远端的 [branch] 去。 如果在你上次提取、合并之后，另有人推送了，Git 服务器会拒绝你的推送，知道你是最新的为止。

五、比较与检查

git log 过滤你的提交历史记录

通过查看分支中另一分支看不到的提交记录，我们已经看到如何用git log来比较分支。 （如果你不记得了，它看起来是这样的：git log branchA ^branchB）。 而且，你也可以用git log去寻找特定的提交。 在此，我们会看到一些更广为使用的 git log 选项，不过哪有很多。 完整的清单可以看看官方文档。
git log –author 只寻找某个特定作者的提交
要过滤你的提交历史，只寻找某个特定作者的提交，你可以使用 --author 选项。 例如，比方说我们要找 Git 源码中 Linus 提交的部分。 我们可以执行类似 git log --author=Linus 的命令。 这个查找是大小写敏感的，并且也会检索电子邮箱地址。 我在此例中使用 -[number] 选项，以限制结果为最近 [number] 次的提交。
$ git log --author=Linus --oneline -5
81b50f3 Move 'builtin-*' into a 'builtin/' subdirectory
3bb7256 make "index-pack" a built-in
377d027 make "git pack-redundant" a built-in
b532581 make "git unpack-file" a built-in
112dd51 make "mktag" a built-in
git log –since –before 根据日期过滤提交记录
如果你要指定一个你感兴趣的日期范围以过滤你的提交，可以执行几个选项 —— 我用 --since 和 --before，但是你也可以用 --until 和--after。 例如，如果我要看 Git 项目中三周前且在四月十八日之后的所有提交，我可以执行这个（我还用了 --no-merges 选项以隐藏合并提交）：

$ git log --oneline --before={3.weeks.ago} --after={2010-04-18} --no-merges
5469e2d Git 1.7.1-rc2
d43427d Documentation/remote-helpers: Fix typos and improve language
272a36b Fixup: Second argument may be any arbitrary string
b6c8d2d Documentation/remote-helpers: Add invocation section
5ce4f4e Documentation/urls: Rewrite to accomodate transport::address
00b84e9 Documentation/remote-helpers: Rewrite description
03aa87e Documentation: Describe other situations where -z affects git diff
77bc694 rebase-interactive: silence warning when no commits rewritten
636db2c t3301: add tests to use --format="%N"

git log –grep 根据提交注释过滤提交记录
你或许还想根据提交注释中的某个特定短语查找提交记录。可以用 --grep 选项。 比如说我知道有个提交是有关使用 P4EDITOR 环境变量，又想回忆起那个改动是啥样子的 —— 我可以用--grep选项找到该提交。

$ git log --grep=P4EDITOR --no-merges
commit 82cea9ffb1c4677155e3e2996d76542502611370
Author: Shawn Bohrer
Date:   Wed Mar 12 19:03:24 2008 -0500

    git-p4: Use P4EDITOR environment variable when set

    Perforce allows you to set the P4EDITOR environment variable to your
    preferred editor for use in perforce.  Since we are displaying a
    perforce changelog to the user we should use it when it is defined.

    Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
    Signed-off-by: Simon Hausmann <simon@lst.de>

Git 会对所有的 --grep和 --author 参数作逻辑或。 如果你用 --grep 和 --author 时，想看的是某人写作的并且有某个特殊的注释内容的提交记录， 你需要加上 --all-match 选项。 在这些例子中，我会用上 --format 选项，这样我们就可以看到每个提交的作者是谁了。
如果我查找注释内容含有 “p4 depo”的提交，我得到了三个提交：

$ git log --grep="p4 depo" --format="%h %an %s"
ee4fd1a Junio C Hamano Merge branch 'master' of git://repo.or.cz/git/fastimport
da4a660 Benjamin Sergeant git-p4 fails when cloning a p4 depo.
1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d

如果我加上 --author=Hausmann 参数，与进一步过滤上述结果到 Simon 的唯一提交相反， 它会告诉我所有 Simon 的提交，或者注释中有“p4 demo”的提交：

$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann"
cdc7e38 Simon Hausmann Make it possible to abort the submission of a change to Pe
f5f7e4a Simon Hausmann Clean up the git-p4 documentation
30b5940 Simon Hausmann git-p4: Fix import of changesets with file deletions
4c750c0 Simon Hausmann git-p4: git-p4 submit cleanups.
0e36f2d Simon Hausmann git-p4: Removed git-p4 submit --direct.
edae1e2 Simon Hausmann git-p4: Clean up git-p4 submit's log message handling.
4b61b5c Simon Hausmann git-p4: Remove --log-substitutions feature.
36ee4ee Simon Hausmann git-p4: Ensure the working directory and the index are cle
e96e400 Simon Hausmann git-p4: Fix submit user-interface.
38f9f5e Simon Hausmann git-p4: Fix direct import from perforce after fetching cha
2094714 Simon Hausmann git-p4: When skipping a patch as part of "git-p4 submit" m
1ca3d71 Simon Hausmann git-p4: Added support for automatically importing newly ap
...

不过，如果加上 --all-match，结果就是我想要的了：

$ git log --grep="p4 depo" --format="%h %an %s" --author="Hausmann" --all-match
1cd5738 Simon Hausmann Make incremental imports easier to use by storing the p4 d

git log -S 依据所引入的差值过滤
如果你写的提交注释都极度糟糕怎么办？或者，如果你要找某个函数是何时引入的，某些变量是在哪里开始被使用的？ 你可以告诉 Git 在每个提交之间的差值中查找特定字符串。 例如，如果我们想要找出哪个提交修改出了类似函数名“userformat_find_requirements”， 我们可以执行（注意在“-S”与你要找的东东之间没有“=”）：

$ git log -Suserformat_find_requirements
commit 5b16360330822527eac1fa84131d185ff784c9fb
Author: Johannes Gilger
Date:   Tue Apr 13 22:31:12 2010 +0200

    pretty: Initialize notes if %N is used

    When using git log --pretty='%N' without an explicit --show-notes, git
    would segfault. This patches fixes this behaviour by loading the needed
    notes datastructures if --pretty is used and the format contains %N.
    When --pretty='%N' is used together with --no-notes, %N won't be
    expanded.

    This is an extension to a proposed patch by Jeff King.

    Signed-off-by: Johannes Gilger
    Signed-off-by: Junio C Hamano

git log -p显示每个提交引入的补丁
每个提交都是项目的一个快照。由于每个提交都记录它所基于的快照，Git 能够经常对它们求差值，并以补丁形式向你展示。 这意味着，对任意提交，你都可以获取该提交给项目引入补丁。 你可以用 git show [SHA]加上某个特定的提交 SHA 获取，或者执行git log -p， 它会告诉 Git 输出每个提交之后的补丁。这是个总结某一分支或者两个提交之间都发生了神马的好途径。

$ git log -p --no-merges -2
commit 594f90bdee4faf063ad07a4a6f503fdead3ef606
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri Jun 4 15:46:55 2010 +0200

    reverted to old class name

diff --git a/ruby.rb b/ruby.rb
index bb86f00..192151c 100644
--- a/ruby.rb
+++ b/ruby.rb
@@ -1,7 +1,7 @@
-class HiWorld
+class HelloWorld
   def self.hello
     puts "Hello World from Ruby"
   end
 end

-HiWorld.hello
+HelloWorld.hello

commit 3cbb6aae5c0cbd711c098e113ae436801371c95e
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri Jun 4 12:58:53 2010 +0200

    fixed readme title differently

diff --git a/README b/README
index d053cc8..9103e27 100644
--- a/README
+++ b/README
@@ -1,4 +1,4 @@
-Hello World Examples
+Many Hello World Examples
 ======================
 This project has examples of hello world in

这是个总结改动，以及合并或发布之前重审一系列提交的好方式。
git log –stat 显示每个提交引入的改动的差值统计
如果 -p 选项对你来说太详细了，你可以用 --stat 总结这些改动。 这是不用 -p，而用 --stat 选项时，同一份日志的输出。

$ git log --stat --no-merges -2
commit 594f90bdee4faf063ad07a4a6f503fdead3ef606
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri Jun 4 15:46:55 2010 +0200

    reverted to old class name

 ruby.rb |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

commit 3cbb6aae5c0cbd711c098e113ae436801371c95e
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri Jun 4 12:58:53 2010 +0200

    fixed readme title differently

 README |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

同样的基本信息，但更紧凑 —— 它仍然让你看到相对改动，和改动了哪些文件。
git diff
最后，要查看两个提交快照的绝对改动，你可以用 git diff 命令。 这在两个主要情况中广为使用 —— 查看两个分支彼此之间的差值，和查看自发布或者某个旧历史点之后都有啥变了。让我们看看这俩情况。
你仅需执行 git diff [version]（或者你给该发布打的任何标签）就可以查看自最近发布之后的改动。 例如，如果我们想要看看自 v0.9 发布之后我们的项目改变了啥，我们可以执行git diff v0.9

$ git diff v0.9
diff --git a/README b/README
index d053cc8..d4173d5 100644
--- a/README
+++ b/README
@@ -1,4 +1,4 @@
-Hello World Examples
+Many Hello World Lang Examples
 ======================

 This project has examples of hello world in
diff --git a/ruby.rb b/ruby.rb
index bb86f00..192151c 100644
--- a/ruby.rb
+++ b/ruby.rb
@@ -1,7 +1,7 @@
-class HiWorld
+class HelloWorld
   def self.hello
     puts "Hello World from Ruby"
   end
 end

-HiWorld.hello
+HelloWorld.hello

正如 git log，你可以给它加上 --stat 参数。

$ git diff v0.9 --stat
 README  |    2 +-
 ruby.rb |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

要比较两个不同的分支，你可以执行类似 git diff branchA branchB 的命令。 不过它的问题在于它会完完全全按你说的作 —— 它会直接给你个补丁文件，该补丁能够将甲分支的最新快照变成乙分支的最新快照的样子。 这意味着如果两个分支已经产生分歧 —— 奔往两个不同方向了 —— 它会移除甲分支中引入的所有工作，然后累加乙分支中的所有工作。 这大概不是你要的吧 —— 你想要不在甲分支中的乙分支的改动。所以你真的需要的是两个分支叉开去时，和最新的乙分支的差别。 所以，如果我们的历史记录看起来像这样：

$ git log --graph --oneline --decorate --all
* 594f90b (HEAD, tag: v1.0, master) reverted to old class name
| * 1834130 (erlang) added haskell
| * ab5ab4c added erlang
|/
*   8d585ea Merge branch 'fix_readme'
...

并且，我们想要看“erlang”分支与主分支相比的查别。执行 git diff master erlang会给我们错误的结果。

$ git diff --stat master erlang
 erlang_hw.erl |    5 +++++
 haskell.hs    |    4 ++++
 ruby.rb       |    4 ++--
 3 files changed, 11 insertions(+), 2 deletions(-)

你可以看到，它加上了 erlang 和 haskell 文件，这确实是我们在该分支中做的， 但是它同时恢复了我们在主分支中改动的 ruby 文件。我们真心想要的只是“erlang”分支中的改动（添加两个文件）。 我们可以通过求两个分支分歧时的共同提交与该分支的差值得到想要的结果：

$ git diff --stat 8d585ea erlang
 erlang_hw.erl |    5 +++++
 haskell.hs    |    4 ++++
 2 files changed, 9 insertions(+), 0 deletions(-)

这才是我们在找的，但是我们可不想要每次都要找出两个分支分歧时的那次提交。 幸运的是，Git 为此提供了一个快捷方式。 如果你执行 git diff master...erlang（在分支名之间有三个半角的点）， Git 就会自动找出两个分支的共同提交（也被成为合并基础），并求差值。

$ git diff --stat master erlang
 erlang_hw.erl |    5 +++++
 haskell.hs    |    4 ++++
 ruby.rb       |    4 ++--
 3 files changed, 11 insertions(+), 2 deletions(-)
$ git diff --stat master...erlang
 erlang_hw.erl |    5 +++++
 haskell.hs    |    4 ++++

2 files changed, 9 insertions(+), 0 deletions(-)
几乎每一次你要对比两个分支的时候，你都会想用三个点的语法，因为它通常会给你你想要的。
顺带提一句，你还可以让 Git 手工计算两次提交的合并基础（第一个共同的祖提交），即git merge-base命令：

$ git merge-base master erlang
8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d
所以你执行下面这个也跟 git diff master...erlang 一样：
$ git diff --stat $(git merge-base master erlang) erlang
 erlang_hw.erl |    5 +++++
 haskell.hs    |    4 ++++
 2 files changed, 9 insertions(+), 0 deletions(-)

当然，我会推荐简单点的那个。
简而言之 使用 git diff 查看某一分支自它偏离出来起与过去某一点之间项目的改动。 总是使用 git diff branchA...branchB 来查看 branchB 与 branchA 的相对差值，这会让事情简单点。