第一课. git简介内容：什么是 git，为什么要使用 git以及获取和学习 git的途径。  欢迎来到 github学习教程的第一课。本教程将通过一系列的实例来介绍如快速，轻松地使用Git。教程中会有很多屏幕截图，希望这样可以让你更好的学习和理解。本节简要介绍 git的概念和为什么应该使用它 git是一个快速，开源，分布式的版本控制系统。因此，它在（开源）和（协作编程社区）很快取代了 svn。

版本控制系统 首先，git是一个版本控制系统，用来保留工程源代码历史状态的命令行工具。类似于SVN，CVS或者 Perforce等工具。当你需要得到以前的一个保存点时，你可以利用它来追踪项目中的文件，并且得到某些时间点提交的项目状态。你可以和合作伙伴共享这些历史状态，将他们的工作和你的工作进行合并，可以对整个工程或某些文件跟历史版本进行比较或者恢复到早期的某个版本。因为 git根本上说是一个命令行工具，所以本教程中的大部分示例都会用命令行的方式给出。教程中使用现行 git版本（1.6系列）编写示例。如果使用早期版本的话，我们也建议您升级到 1.6系列。当然，现在已经有很多 git UI的工具，使得 git变得更加简单易用。git的安装：下载地址http://www.kernel.org/pub/software/scm/git/ 安装过程：1.$ tar xzvf git-1.6.52.$ cd git-1.6.53.$ ./config --prefix=/usr/local4.$ make5.$ sudo make install6.$ git --version

如果需要命令帮助的话，可以键入'-help'就会显示出操作手册。你也可以键入'git help command'实现同样的目的。$ git log --help$ git help log

开源 

git是一个开源项目，有很多年的历史了，它的大部分内容都是用C来写的。

你可以得到整个项目的源代码，加以分析和改进。下载源程序的地址：git-scm.com/download。git许可证：GNU通用公共许可证（GNU General Public License）离线，速度快   git是完全的分布式处理，这意味着它可以离线工作。跟VCS工具例如 Perforce或者SVN完全不同，Git的所有操作几乎不需要网络连接，包括历史回顾，差异显示和提交。这也意味着Git比其他的VCS工具要快很多，因为某些VCS工具对网络的依赖会导致时间上的延迟。下面来看看'log'命令分别运行在 git和 SVN上的结果：[master]$ time git log > /dev/null

real 0m0.352suser 0m0.300ssys 0m0.034s 

$ time svn log > /dev/null

real 0m3.709suser 0m0.482ssys 0m0.168s

git仅用了 0.3秒而 SVN用了 3.7秒。你会发现几乎所有的命令都有这样的时间差异。例如，添加知名的 famfamfam出品的图标集并提交，因为使用 git可以将【提交（commit）】和【上传（'push'）网络】这两个步骤分开，其中【提交（commit）】git只用 1/4秒，而SVN会用到 45秒。time 'git add icons; git commit -m "added icons"'

real 0m0.273suser 0m0.032ssys 0m0.008s

time 'svn add icons; svn commit -m "added icons"'

real 0m45.276suser 0m15.997ssys 0m5.503s

即使是再加上用 git 提交（commit）之后再上传（push）到网络共享仓库中的时间，也比 SVN的耗时要少的多的多。time git push

real 0m6.219suser 0m0.023ssys 0m0.011s

如果你仅仅是想提交然后继续工作，你就会感觉到时间上的巨大差异--因为 git的工作流程跟以前的版本控制系统不大一样。git的命令大部分都是即时的，不像以前，执行'svn commit'命令之后，可以喝杯咖啡再回来继续工作。

比 svn更小git比较节省空间。举例来说，一个Django项目如果使用现行的源代码控制系统(source control systems)来实现版本控制的话，git克隆(clone)是最小的。$ du -d 1 -h108M ./django-bzr 44M ./django-git 53M ./django-hg 53M ./django-svn

更神奇的是，虽然 git克隆比 SVN要小很多，但是 git克隆包含整个项目的历史版本---从第一次提交之后的每一个文件的每一次提交的版本都囊括了。然而，SVN只包含项目的最后一个版本。

快照，而不是变更集跟其他的VCS工具不同，git是基于快照的。不再是考虑将提交点存储成补丁文件，而是在你提交项目的时候对项目做一个简单的快照。提交的东西包含一些元数据（提交信息（message），作者，日期等等），一个提交点指向这次提交时项目的快照。

记住这个图对于给定情形下使用Git是非常有帮助的。如果要了解更深层次的Git存储数据的只是，可以访问Git for computer scientists

分支和合并也许 git最显著的一个特点就是它的分枝模型了，因为它改变了开发者工作的基本模式。以前的VCS工具分枝的方法是对每一个分枝都放到一个独立的目录中。而 git可以让你在同一个工作目录中切换（switch）到不同的分枝。创建和切换分枝几乎是即时的（instant），而且并不是所有的分枝都需要上传到 git仓库中去共享，对于某些你更愿意隐藏在本地的工作来说，git无疑提供了很大的便利。从这点上来说，git确是有其独到之处。摒弃了CVS只对项目开发主线创建分枝的做法，git开发者可以随时创建，合并，删除多个分枝。通常对于实现某个功能或者每个 debug

阶段，都可以创建它的分枝，当完成之后再将其进行合并。这种模式可以让开发者体验更加快速，简便，安全的方式来开发项目。它鼓励一种

非线性的开发周期，它可以说是并行的多线程模式而不是多个步骤串行的模式。安装 git

参见 git community book 中对于 git安装在不同操作系统中的说明。资源关于 git的更多信息，可以参考 git-scm.com

第二课.配置和初始化 

配置 git

在使用 git之前你需要配置一下 git。git在你创建提交的时候会记录你的名字和 email地址，所以你应该告诉 git这些内容。可以使用'git config'命令来设置，如果传递参数'-global' ，它会将这些值记录在~/.gitconfig文件里，作为这些配置的默认值。$ git config --global user.name "Scott Chacon"$ git config --global user.email "schacon@gmail.com"

在使用 git的过程中，经常会用到文本编辑器。默认情况下它使用的是 vim。如果你喜欢用其他的编辑器，例如 emacs，你可以这样设置：$ git config --global core.editor 'emacs'

查看设置值可以通过这样的命令：$ git config user.name

你也可以自己编辑文件内容。git首先会检查'/etc/gitconfig'，然后是'~/.gitconfig'最后是'.git/config'，这些文件里的内容格式类似这样：$ cat ~/.gitconfig [user]name = Scott Chaconemail = schacon@gmail.com 

2.初始化一个新的 git仓库在一个已存在的目录中初始化 git存储，只要在目录下输入'git init'命令即可。这样会为这个目录生成一个基本的 git存储框架。$ rails myproject$ cd myproject$ git init

现在，就有了一个空的 git存储（你可以查看目录下的'.git'目录）。现在就可以 stage和提交（commit）文件到这个目录了。分别使用'git add'和'git commit'命令。下一节深入讲解这些命令。$ git add .$ git commit -m 'initial commit'

这样你就有了一个完整的提交之后的 git存储了，可以运行'git log'（下一节深入讲解）$ git log commit eac2f939e6a1cb3189fedd19919888d998ab0431Author: Scott Chacon <schacon@gmail.com>Date:   Sun Feb 8 07:55:57 2009 -0800    initial commit

克隆一个 git仓库git可以通过很多的协议进行网络通信，其中有三个最主要的协议，分别是ssh，http，git（专职为 git服务的协议）匿名访问方式：通过 git://或者 http.不管使用何种协议克隆 git存储，格式都是这样：'git clone uri'， uri的格式："git://(hostname)/(path).git"

 $ git clone git://github.com/schacon/munger.git$ cd munger$ git log

当然也可以使用 http克隆，跟上面的类似，就是将 git换成了 http。$ git clone http://github.com/schacon/munger.git

这仅仅适用于服务器支持这两种协议的情况。如果服务器是GitHub的话，这两种方式都是可以的

现在你已经有一个 git本地仓库，一切都配置完毕。然后该怎么办？一般来说，跟其他的源码控制系统的工作流程没什么两样，唯一一个区别就是载入（stage）的过程。整个工作流程大致是这样（流程 1）：

与远程仓库同步 修改文件 查看变更 载入变更 提交载入的变更 重复 上传这是最复杂的情况，如果你不与别人合作开发的话，就不需要上传到仓库中去（流程2）：* 修改文件* 提交变更* 重复简单吧。要记得，git是分布式的，所以如果不是合作项目的话，实际上不需要提交到一个公共的共享服务器上--你可以像使用RCS一样，只用来追踪本地文件变更。下面，让我们先来看个简单的示例，紧接着再来看用 git协作开发的实例。简单示例如果你想跟着做这个例子，请克隆这个项目：$ git clone git://github.com/schacon/simplegit 

例子开始，按照流程 2，我们首先要修改README文件，将自己添加到项目作者中去。所以我们修改这个文件。然后我们希望提交这个变更，所以我们运行'git commit -a' 命令。 -a 的意思是告诉 git先将变更了的文件先载入（stage），然后提交-我们后面会通过'staging area'命令实现，但是现在运行 'git commit -a' 命令，效果跟在 SVN中使用'commit'命令一样。$ git commit -a执行完之后，一个提交信息的提示会出现在编辑器中（这里$EDITOR环境变量或'core.editor'这两个 git配置变量的默认值都是 vim）类似下面这样的内容：

_# Please enter the commit message for your changes. Lines starting# with '#' will be ignored, and an empty message aborts the commit.# On branch main# Changes to be committed:#   (use "git reset HEAD <file>..." to unstage)## modified:   README#                                                                      ~                                                                                      ~                                                                                      ".git/COMMIT_EDITMSG" 9L, 253C输入一些提交的信息，譬如"added myself to the README as an author"然后退出。vim操作提示：按下 I,o,a进入编辑模式，编辑完毕按 Esc，输入:wq保存退出。然后会看到这样的提示：[master]: created 5896d4d: "added myself to the README as an author" 1 files changed, 2 insertions(+), 1 deletions(-) 显示我们刚刚输入的提交信息，并且有一组关于这次提交项目中文件变更的统计数字。同时还给我们一个提交的校验和，'5896d4d',这个校验和可以用来日后确切的查看这次提交的细节。这就是简单用例。修改文件，'git commit -a'，重复协作开发示例现在，我们来介绍一个复杂点的实例，这次我们使用远程仓库，将项目上传上去，从而跟其他的开发者一起协同工作。同时，我们会介绍 staging area。如果你会从远程仓库中克隆项目，那么与远程仓库项目同步也是相当简单的--只需要执行'git pull'.如果是远程仓库项目没有变化，也就是说其他的开发者没有对项目进行变更，会显示这样的信息：Already up-to-date.相反，执行这条命令之后会将你上次同步之后远程仓库中的变更同步到本地项目中，并且git会合并这些新的变更：$ git pullUpdating c264051..b04dc3dFast forward lib/simplegit.rb |    4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)例子开始，重新克隆远程仓库中的项目，修改README文件和 lib/simplegit.rb文件（不要执行 git commit -a）。现在你可以使用'git status'命令来查看工作目录发生了什么变更：$ git status# On branch master

# Changed but not updated:#   (use "git add <file>..." to update what will be committed)#   (use "git checkout -- <file>..." to discard changes in working directory)## modified:   README# modified:   lib/simplegit.rb#no changes added to commit (use "git add" and/or "git commit -a")我们看到，有两个文件是在"changed but not updated"段落中出现 ，这意味着这两个文件还没有载入（unstaged）. 如果现在我们提交，什么也不会发生。也就是说文件必须先载入（stage），然后才能提交。

所以，我们先来载入（stage） 文件，git中使用'git add'命令不仅可以开始追逐文件而且可以对他们载入 stage变更。所以让我们载入（stage） README文件的变更，然后再来查看一下状态。$ git add README$ git status# On branch master# Changes to be committed:#   (use "git reset HEAD <file>..." to unstage)## modified:   README## Changed but not updated:#   (use "git add <file>..." to update what will be committed)#   (use "git checkout -- <file>..." to discard changes in working directory)

## modified:   lib/simplegit.rb现在'lib/simplegit.rb'文件还是未载入（unstaged）, 但是README文件现在已经到了'changes to be committed'段落中-它几经载入（stage）了。现在如果我们运行提交命令（不要-a,这个会自动 stage所有的东西），只有这个文件会被提交-而 simplegit.rb依然是 unstaged。这时，我们使用-m选项来执行'git commit'，这样后面跟上字符串表示这次提交的信息。$ git commit -m 'updated the README'[master]: created 14bb3c6: "updated the README" 1 files changed, 1 insertions(+), 2 deletions(-)如果现在再执行'git status'，我们会看到 stage之后的文件现在已经提交了，只剩下了unstaged的'simplegit.rb'文件。$ git status# On branch master# Your branch is ahead of 'origin/master' by 1 commit.## Changed but not updated:#   (use "git add <file>..." to update what will be committed)#   (use "git checkout -- <file>..." to discard changes in working directory)## modified:   lib/simplegit.rb#现在我们可以 stage并且提交这个文件：$ git commit -a -m 'added a staging command to the library'[master]: created bbaee85: "added a staging command to the library" 1 files changed, 4 insertions(+), 0 deletions(-)$ git status# On branch master# Your branch is ahead of 'origin/master' by 2 commits.#nothing to commit (working directory clean)现在我们已经将两次提交的变更都搞定了，而且加了提交信息，可以让我们的合作伙伴很容易理解我们做的变更。经过最后一次提交，我们看到'git status'执行之后显示我们的工作目录 clean了（同时提示我们现在的分枝上有两个提交还没有上传）所以，现在我们将这些变更上传到服务器端与我们的合作伙伴分享，前提是我们有上传的权限，（如果没有上传的权限，我们可以在网络上创建一个自己的 git仓库，将其上传），然后让朋友下载。运行'git push'会将我们的变更上传到服务器。$ git pushCounting objects: 11, done.Compressing objects: 100% (6/6), done.Writing objects: 100% (7/7), 744 bytes, done.Total 7 (delta 3), reused 0 (delta 0)

To git@github.com:schacon/simplegit.git   b04dc3d..bbaee85  master -> master

到目前为止，我们看到了新数据都已经上传完毕，服务器上的主分支也已经更新了。现在我们可以复习一下这整个的过程，让我们可以更加熟练的将 git应用到我们的项目中去。 

Git学习教程（四）：分枝和合并2009-12-17 21:12:20标签：教程 学习 合并 git 分枝原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://fsjoy.blog.51cto.com/318484/245081

第四课  分枝和合并基础知识介绍 

内容提要：创建工作分枝，合并分枝以及删除分枝 

从第一课的介绍中，我们了解到，git处理分枝和合并是非常独到的。首先，无论是创建新分枝还是分枝之间切换，都表现出一个共同的特征--快！ git 有一个独立的工作目录，专门用来存放所有分枝的内容，所以你没必要为每一个分枝再分别创建目录。这一节，我们的任务是：1. 创建一个新的分枝；2.在这个分枝上做一些工作；3.切换回稳定的主分枝（一般 git默认的主分枝名叫master）；4.在主分枝上再做点工作；5.再切换到刚那个临时分枝完成工作；6.最后将它们合并成为一个稳定的主分枝。 

首先，查看现存的分枝，可以使用不带任何参数的'git branch'命令。$ git branch

* master

可以看到，我们现在只有一个分枝叫做'master'，*代表的意思是我们正在这个主分枝上工作。下图是在主分支上的提交历史模型，绿框表示提交，箭头指向的是它的父节点。这就是 git提交数据的方式。 

从图中可以看出，在 git中，分枝都是由一些具体的提交点组成。整个分枝的历史都是这样串联起来的，一次只有一个提交点。创建新的分枝可以用'git branch (branchname)'命令在当前分枝上创建一个新的分枝：$ git branch experiment

为了将我们的工作保存到 experiment分枝而不是master分枝上，我们需要切换到experiment分枝上，执行'git checkout'命令：$ git checkout experiment

Switched to branch "experiment"

$ git branch

* experiment

  master

执行完毕后，我们就切换到了新的分枝（experiment）分枝上，看到 experiment前面有了*号了。现在，我们修改文件、提交就不用再担心跟master分枝混在一起了。也没必要在我们确定一切搞定之前，将 experiment分枝上的变更共享了。在多分枝上进行工作现在，让我们添加一个 TODO文件，并修改 simplegit.rb文件，然后将这些变更都提交。$ vim lib/simplegit.rb

$ vim TODO

$ git add TODO

$ git commit -am 'added a todo and added simplegit functions'

[experiment]: created 4682c32: "added a todo and added simplegit

functions"

 2 files changed, 10 insertions(+), 0 deletions(-)

 create mode 100644 TODO

现在，我们来看一下，整个项目中有 3个文件和一个子目录。$ ls

README  Rakefile TODO  lib

然后，我们假设需要回到原始版本来调试 simplegit.rb文件。$ git checkout master

Switched to branch "master"

$ ls

README  Rakefile lib

可以看到我们已经回到了master分枝，工作目录中也没有 TODO文件，这是因为master分枝上我们就没有创建过这个文件。如果现在我们再切换到 experiment分枝，我们又会看到 TODO文件，并且simplegit.rb也是我们在 experiment修改后的内容。 

下面这段代码是在master分枝上修改 simplegit.rb文件，在文件内添加一个 commit

function.提交，然后再切换到 experiment分枝。 

$ vim lib/simplegit.rb 

$ git commit -am 'added a commit function'

[master]: created 0b7434d: "added a commit function"

 1 files changed, 4 insertions(+), 0 deletions(-)

$ git checkout experiment

Switched to branch "experiment"

$ ls

README  Rakefile TODO  lib

很多使用 git的开发者通常会同时拥有很多个分枝，每一个分枝上都会进行着某个具体功能的开发，这些开发可能持续几分钟、几小时，也可能长时间的在某个分枝上进行大规模重构的工作，并定期的将其合并到主分枝上。如果你需要在一个长期工作的分支上与其他开发者进行协作，你可以将这个分枝上传到共享服务器端。譬如，如果你想跟某人共享 experiment分枝，你可以这样：$ git push origin experiment

让你的合作伙伴同步这个分枝，然后与你协同工作。当然你也可以自己保留这些分枝作为自己的工作分枝--不用上传就可以了。合并和移除无用分枝当你在一个分枝上完成你的工作了，这时，如果你觉得所做的工作没什么意义，那么你可以忽略它并且将其移除；相反，你应该将这些工作合并到一个你会长期使用的分枝中（一般来说，开发者会用'master'分枝来存放稳定的代码，并行的'develop'分枝用来整合或测试变更的内容，或者将一些短期的分枝合并进来）。合并分枝的方法：首先切换到想要合并到的分枝下，运行'git merge'命令，（例如本例中将 experiment分枝合并到master分枝的话，进入master分枝运行 git merge

experiment命令）如果合并顺利的话：$ git merge experiment

Auto-merging lib/simplegit.rb

Merge made by recursive.

 lib/simplegit.rb |    1 +

 1 files changed, 1 insertions(+), 0 deletions(-)

 

合并冲突处理然而，有时候合并并不一定会顺利进行，如果碰到了问题，就会出现下面这些内容：$ git merge experiment

Auto-merging lib/simplegit.rb

CONFLICT (content): Merge conflict in lib/simplegit.rb

Automatic merge failed; fix conflicts and then commit the result.

这种情形下，提示合并冲突，你可以通过下面的方式来解决：打开提示冲突的文件，会看到冲突标记：<<<<<<< HEAD:lib/simplegit.rb

  def commit(message)

    command("git commit -m '#{message}'")

=======

  def add(path)

    command("git add #{path}")

>>>>>>> experiment:lib/simplegit.rb

  end

修改完成之后，运行'git add'重新载入(re-stage)这个文件，然后合并：$ git add lib/simplegit.rb

$ git commit

[master]: created 6d52a27: "Merge branch 'experiment'"

 

多次合并这个问题之所以重要是因为在其他的VCS工具中多次合并实现起来是很麻烦的，但是用git，很容易解决。合并一个分枝之后，再继续在这个分枝上工作，然后再合并。这种情形一般是这样的：如果你有一个'development'分枝，你正在进行集成测试、合并实验中的变更，然后定期的将其合并到稳定的'master'分枝中。 

用我们正在进行的例子来讲，假如我们现在又切换到'experiment'分枝，做点小小的改动，然后再将其合并到'master'分枝中，整个的过程大致是这样：

因为 git合并是基于提交历史的快照，所以多次合并显得 so easy。当你在一个分枝上做完你的工作之后，譬如例子中的'experiment'分枝，那么我们只需使用'git branch -d'命令即可删除此分枝$ git branch -d experiment

如果分枝还没有被合并，那么执行这个命令就会将分枝上所做的工作一并删除，git是不允许你这么干的。如果你实在想删除的话，那么使用'-D'参数强行删除吧。 

这就是 git中分枝和合并的所有内容，我想你理解了 git的这一功能之后会觉得它确实是个非常棒的工具了。

Git学习教程（五）：Git标签2009-12-17 22:28:20标签：git 标签  休闲 学习教程 职场 git原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://fsjoy.blog.51cto.com/318484/245106

第五课 Git标签

内容提要：创建有签名，无签名、轻量级标签来永久的标记项目历史中的关键点 

跟大多数的VCS工具一样，git也有在历史状态的关键点“贴标签”的功能--一般人们用这个功能来标记发布点（例如'v1.0'）。这节课我们学习如何使用标签列表，创建新标签，以及在 git中有哪些不同类别的标签。 

列出 git中现有标签 

要想列出 git中现有的所有标签，输入'git tag'命令运行即可：$ git tag

v0.1

v1.3

这个列表是按照字母表顺序给出的，其实排名先后跟重要程度没有直接联系。当然，你也可以按照特定表达式搜索某些标签。假如在一个 git仓库中有超过 240个标签，而你只想得到 1.4.2序列的标签，那么你可以：$ git tag -l v1.4.2.*

v1.4.2.1

v1.4.2.2

v1.4.2.3

v1.4.2.4

创建标签在 git中有两种最主要的标签--轻量级标签（lightweight）和带注释的标签（annotated）。轻量级标签跟分枝一样，不会改变--它就是针对某个特定提交的指针。然而，带注释的标签是 git仓库中的对象。它是一组校验和，包含标签名、email、日期，标签信息，GPG签名和验证。一般情况下，建议创建带注释的标签，这样就会保留这些信息，但是如果你只是需要临时性标签或者某些原因你不想在标签中附带上面说的这些信息，lightweight标签更合适些。带注释的标签

在 git中创建带注释的标签非常简单，在运行'tag'命令时加上-a就可以了。

$ git tag -a v1.4 -m 'version 1.4'

$ git tag

v0.1

v1.3

v1.4

'-m'指明标签信息，跟标签一起存储。如果你不使用-m指明标签信息，git会自动启动文本编辑器让你输入。可以使用 git show 命令查看相应标签的版本信息，并连同显示打标签时的提交对象。$ git show v1.4

tag v1.4

Tagger: Scott Chacon <schacon@gmail.com>

Date:   Mon Feb 9 14:45:11 2009 -0800

my version 1.4

commit 15027957951b64cf874c3557a0f3547bd83b3ff6

Merge: 4a447f7... a6b4c97...

Author: Scott Chacon <schacon@gmail.com>

Date:   Sun Feb 8 19:02:46 2009 -0800

    Merge branch 'experiment'

我们可以看到，在提交对象信息上面，列出了此标签的提交者和提交时间，以及相应的标签信息。有签名的标签

如果你有GPG私钥的话，你也可以用GPG来给你的标签签名，把-a换成-s就可以了：[master]$ git tag -s v1.5 -m 'my signed 1.5 tag'

You need a passphrase to unlock the secret key for

user: "Scott Chacon <schacon@gmail.com>"

1024-bit DSA key, ID F721C45A, created 2009-02-09

然后，如果你对某个标签运行'git show'的话，你就会看到你的GPG前面附加上去了。[master]$ git show v1.5

tag v1.5

Tagger: Scott Chacon <schacon@gmail.com>

Date:   Mon Feb 9 15:22:20 2009 -0800

my signed 1.5 tag

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.8 (Darwin)

iEYEABECAAYFAkmQurIACgkQON3DxfchxFr5cACeIMN+ZxLKggJQf0QYiQBwgyS

N

Ki0An2JeAVUCAiJ7Ox6ZEtK+NvZAj82/

=WryJ

-----END PGP SIGNATURE-----

commit 15027957951b64cf874c3557a0f3547bd83b3ff6

Merge: 4a447f7... a6b4c97...

Author: Scott Chacon <schacon@gmail.com>

Date:   Sun Feb 8 19:02:46 2009 -0800

    Merge branch 'experiment'

稍后，我们会介绍如何验证签名标签。轻量级标签

轻量级标签实际上就是存在一个文件中的提交校验和--没有附加任何其他信息。创建轻量级标签的方法就是把上面'-a','-s','-m'这些选项都去掉。$ git tag v1.4-lw

$ git tag

v0.1

v1.3

v1.4

v1.4-lw

v1.5

如果现在对这个标签使用'git show'命令，不会看到像上面那种标签显示的那么多内容，仅仅显示这次提交的有关信息。$ git show v1.4-lw

commit 15027957951b64cf874c3557a0f3547bd83b3ff6

Merge: 4a447f7... a6b4c97...

Author: Scott Chacon <schacon@gmail.com>

Date:   Sun Feb 8 19:02:46 2009 -0800

    Merge branch 'experiment'

验证标签使用'git tag -v (tag)'就可以验证一个签名标签了。这个命令会用到GPG来验证签名。前提是：你必须在密钥环中存放着签名者的公钥。$ git tag -v v1.4.2.1

object 883653babd8ee7ea23e6a5c392bb739348b1eb61

type commit

tag v1.4.2.1

tagger Junio C Hamano <junkio@cox.net> 1158138501 -0700

GIT 1.4.2.1

Minor fixes since 1.4.2, including git-mv and git-http with alternates.

gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID

F3119B9A

gpg: Good signature from "Junio C Hamano <junkio@cox.net>"

gpg:                 aka "[jpeg image of size 1513]"

Primary key fingerprint: 3565 2A26 2040 E066 C9A7  4A7D C0C6 D9A4 F311

9B9A

如果你没有这个公钥的话，你会看到这样的信息：gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID

F3119B9A

gpg: Can't check signature: public key not found

error: could not verify the tag 'v1.4.2.1'

后期贴标签

这种情况是说你想对以前的某次提交贴个标签，如果整个提交历史是这样的：$ git log --pretty=oneline

15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'

a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support

0d52aaab4479697da7686c15f77a3d64d9165190 one more thing

6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'

0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function

4682c3261057305bdd616e23b64b0857d832627b added a todo file

166ae0c4d3f420721acbb115cc33848dfcc2121a started write support

9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile

964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo

8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme

忘记在那个提交信息为'updated rakefile'的点上贴一个'v1.2'的标签了，我可以现在贴一个上去。你可以在执行创建标签的语句后面跟上那次提交的校验和（或者部分校验和）。$ git tag -a v1.2 9fceb02

现在我们可以列出所有的标签：

$ git tag 

v0.1

v1.2

v1.3

v1.4

v1.4-lw

v1.5

$ git show v1.2

tag v1.2

Tagger: Scott Chacon <schacon@gmail.com>

Date:   Mon Feb 9 15:32:16 2009 -0800

version 1.2

commit 9fceb02d0ae598e95dc970b74767f19372d61af8

Author: Magnus Chacon <mchacon@gmail.com>

Date:   Sun Apr 27 20:43:35 2008 -0700

    updated rakefile

...

共享标签

默认情况下，'git push'命令不会将标签上传到远程服务器上。为了共享这些标签，你必须在'git push'命令后明确添加-tags选项

[master]$ git push --tags

Counting objects: 50, done.

Compressing objects: 100% (38/38), done.

Writing objects: 100% (44/44), 4.56 KiB, done.

Total 44 (delta 18), reused 8 (delta 1)

To git@github.com:schacon/simplegit.git

 * [new tag]         v0.1 -> v0.1

 * [new tag]         v1.2 -> v1.2

 * [new tag]         v1.4 -> v1.4

 * [new tag]         v1.4-lw -> v1.4-lw

 * [new tag]         v1.5 -> v1.5

现在，如果有人克隆或者在线同步你的 git仓库的话，标签也会一并同步了。

it学习教程（六）Git日志2009-12-18 12:47:51标签：日志 教程 学习 休闲 git原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://fsjoy.blog.51cto.com/318484/245261

第六课 Git 日志

内容提要：浏览项目历史，查询指定提交内容，图形化显示分枝和合并...

'git log'是 git中最常用的一个命令，执行之后，会显示该项目的提交历史。如果命令不加任何参数，那么就会显示目前所在分枝上，从最后一次提交开始，按时间顺序依次向前排列的所有提交历史记录。

$ git log

commit 166ae0c4d3f420721acbb115cc33848dfcc2121a

Author: Scott Chacon <schacon@gmail.com>

Date:   Sun Feb 8 16:50:43 2009 -0800

    started write support

commit 9fceb02d0ae598e95dc970b74767f19372d61af8

Author: Magnus Chacon <mchacon@gmail.com>

Date:   Sun Apr 27 20:43:35 2008 -0700

    updated rakefile

commit 964f16d36dfccde844893cac5b347e7b3d44abbc

Author: Magnus Chacon <mchacon@gmail.com>

Date:   Sun Apr 27 20:34:23 2008 -0700

    commit the todo

上面显示了 3次提交，对于每一次的提交都会显示四方面内容，分别是：*提交的校验和*作者信息（作者名和 email地址） *提交日期 *提交信息 

这是 git日志默认输出的提交历史的内容格式。多数情况下，这样输出还是比较完美的。然而，有时候你只是想看到某个分枝上的最后几条提交信息，或者某些感兴趣的数据，只要在'git log'命令后面加上相应的参数，它就可以做更多有意义的事情。日志输出格式

通过'git log'命令还能有很多种可选的输出格式。 

显示补丁 

你可以查看每一次提交条目的补丁内容，只需要在'git log'后加上-p选项，这在代码复查时很管用--在合并到你的某个分枝之前查看是其他作者提交了什么内容，或者是看看在最后发布之前所做的修改。$ git log -p

commit 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc

Author: Scott Chacon <schacon@gmail.com>

Date:   Sun Feb 8 18:29:31 2009 -0800

    added a commit function

diff --git a/lib/simplegit.rb b/lib/simplegit.rb

index dd6b7b3..c75a3e6 100644

--- a/lib/simplegit.rb

+++ b/lib/simplegit.rb

@@ -9,6 +9,10 @@ class SimpleGit

     command("git status")

   end

+  def commit(message)

+    command("git commit -m '#{message}'")

+  end

+

   def show(treeish = 'master')

     command("git show #{treeish}")

   end

commit 166ae0c4d3f420721acbb115cc33848dfcc2121a

Author: Scott Chacon <schacon@gmail.com>

Date:   Sun Feb 8 16:50:43 2009 -0800

    started write support

diff --git a/lib/simplegit.rb b/lib/simplegit.rb

index dd6b7b3..e7dfaa9 100644

--- a/lib/simplegit.rb

+++ b/lib/simplegit.rb

@@ -9,6 +9,10 @@ class SimpleGit

     command("git status")

   end

+  def add(path)

+    command("git add #{path}")

+  end

+

   def show(treeish = 'master')

     command("git show #{treeish}")

   end

内容相当的冗长，但是这些输出都是分页的，所以一旦你得到了你需要的信息，后面的提交内容就可以都跳过了。

 

查看统计数字你可以通过执行'git log -stat'命令，来显示被修改文件的修改统计信息，添加或删除了多少行。$ git log --stat

commit 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc

Author: Scott Chacon <schacon@gmail.com>

Date:   Sun Feb 8 18:29:31 2009 -0800

    added a commit function

 lib/simplegit.rb |    4 ++++

 1 files changed, 4 insertions(+), 0 deletions(-)

commit 166ae0c4d3f420721acbb115cc33848dfcc2121a

Author: Scott Chacon <schacon@gmail.com>

Date:   Sun Feb 8 16:50:43 2009 -0800

    started write support

 lib/simplegit.rb |    4 ++++

 1 files changed, 4 insertions(+), 0 deletions(-)

 

调整显示格式 

使用'git log --pretty=format'命令，可以将提交历史显示成你想要的格式。这里 format

的可选项包括：oneline，short，medium，full，fuller，email，raw。每种格式都有侧重的显示相关内容。

$ git log --pretty=raw

commit 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc

tree dbcff814ec9fbbd3487171a7eaca73cf0069ba53

parent 85211d1138cb91f25c0633d361ff5f6e00677bc5

author Scott Chacon <schacon@gmail.com> 1234146571 -0800

committer Scott Chacon <schacon@gmail.com> 1234146571 -0800

    added a commit function

commit 166ae0c4d3f420721acbb115cc33848dfcc2121a

tree e67636948570e27a9c2bf2699ecafadf729c3efc

parent 9fceb02d0ae598e95dc970b74767f19372d61af8

author Scott Chacon <schacon@gmail.com> 1234140643 -0800

committer Scott Chacon <schacon@gmail.com> 1234140643 -0800

    started write support

这里，最常用的一种格式是'oneline', 每一行表示一次提交，一行内容包括校验和与提交信息两项内容。这种显示格式可以很简洁的显示大量的提交信息。$ git log --pretty=oneline

0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function

166ae0c4d3f420721acbb115cc33848dfcc2121a started write support

9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile

964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo

8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme

a5f4a0daa9b13bb85283461ddaba6e589e34ccb5 added cat-file

 

自定义格式如果你希望 git输出自定义的提交信息，你可以使用这样的命令：git log --

pretty=format:"(format)".可以在""内自定义字符串与Git变量相结合的显示格式，在输出时，git会自动的将变量的位置输出为所需内容。$ git log --pretty=format:"The author of %h was %an, %ar%nThe

title was >>%s<<%n"

The author of 0b7434d was Scott Chacon, 18 hours ago

The title was >>added a commit function<<

The author of 166ae0c was Scott Chacon, 20 hours ago

The title was >>started write support<<

The author of 9fceb02 was Magnus Chacon, 10 months ago

The title was >>updated rakefile<<

The author of 964f16d was Magnus Chacon, 10 months ago

The title was >>commit the todo<<

The author of 8a5cbc4 was Scott Chacon, 5 months ago

The title was >>updated readme<<

更多详细自定义格式方法可以参考 git log docs 。分枝拓扑图 

还有一个日志输出选项是-graph，这个选项与--pretty=oneline结合不仅可以显示提交历史而且还会显示图形化的分枝拓扑$ git log --pretty=oneline --graph

*   15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'

|\  

| * a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support

* |   4a447f750f910445e38338aadef48f3038b35d2b sweet

|\ \  

| |/  

| * 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing

* |   6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch

'experiment'

|\ \  

| |/  

| * 4682c3261057305bdd616e23b64b0857d832627b added a todo file

| * ebe0d698d3def0ec43f9b883857717de8c405d96 removed the todo file

| * 166ae0c4d3f420721acbb115cc33848dfcc2121a started write support

* | 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function

* | 85211d1138cb91f25c0633d361ff5f6e00677bc5 removed todo file

|/  

* 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile

提交查询过滤器

利用提交查询过滤器可以查询经过某些条件限制后得到的提交信息。日期区间

'git log'命令后如果跟-before和-after选项，就会显示两个日期之间的提交条目。日期格式也有不同的可选格式。例如，我想查看 1月 26号之后，2个星期之前的提交内容，可以运行：$ git log --before="2 weeks ago" --after="2009-01-26" --pretty=oneline

dfb047b9e4f7f66c5322ef642f21fd92b0a975e3 Mention "local convention"

rule in t

25655221745fd27d5da3bda7ad0fe49f2005d776 Windows: Revert to default

paths and

35fb0e8633217f602360a9987af51c4b960e7850 Compute prefix at runtime if

RUNTIME

8e3462837b0ace04357503a3f58802cc2231df29 Modify setup_path() to only

add git_

2fb3f6db96492b680899f9e40f434eeb4c778a84 Add calls to

git_extract_argv0_path(

2cd72b0b290e40fb4d6a925ce26603503f01aa09 git_extract_argv0_path():

Move check

4dd47c3b867f51211d0dc4474dab0fee5ca614da Refactor

git_set_argv0_path() to git

026fa0d5ad9538ca76838070861531c037d7b9ba Move computation of

absolute paths f

 

贡献者过滤器

 

git还可以通过贡献者过滤器来查看某个作者发起的提交。在 commit对象中实际上存在两个人的记录--一个是作者(author)，也就是做原始提交的人。第二个人名是提交者(committer)，就是提交到仓库中的人。在这里找不到合适的翻译，所以把二者统称为贡献者。一般情况下，所指的都是同一个人，但是在某些情况下就不是了--譬如，有一个作者将他写的东西 email给项目持有人，这个项目持有人就是提交者(committer)，项目持有人将作者提交的东西提交到 git仓库中。 

大多数情况搜索的是作者，当然你可以通过-author或者-committer加名字的方式来搜索相应的提交条目。下面这个例子我们是执行命令来查找作者名（author）为 Johannes

Schindelin，在过去两周内的所有提交条目：$ git log --author=johannes.schindelin --since="14 days ago" --pretty=oneline

26be15f09db15d2b53a13d0f184d77fb54367f33 filter-branch: do not consider

diver

e1e4389832f32bb6ce029d6a6b110aa9ec768ea8 apply: fix access to an

uninitialize

418566b6fdcc0eb1b5549d0742366aa13a7ff277 Fix 'git diff --no-index' with a

non

f7951e1d97aeb7b3ed359faeab5edf9e870ec8a5 Simplify t3412

37e5c8f46042510176a71d73c903c44214e09815 Simplify t3411

4bd03d15e495086a38470b59447296db4c235cb9 Simplify t3410

008849689e04e774aa7b194cd690405761e2383a test-lib.sh: introduce

test_commit()

03af0870a0e6d551a31eb830d5c2682b82ae0ac6 lib-rebase.sh: Document

what set_fak

29a03348a336f28025c824436a713cb9cb01b7a6 t3404 & t3411: undo

copy&paste

b8469ad0578d6b84ec92752a5f8df3ca5828af77 test-path-utils: Fix off by one,

fou

f265458f6116a0c03200477ae3b839f2a75bf0fa get_sha1_basic(): fix invalid

memory

你可以指定完整人名或 email地址来搜索，你也可以使用这些值的部分内容来查询，譬如，搜索 Junio Hamano作者的提交内容，可以执行下面的任意一条语句：

$ git log --author=Junio

$ git log --author=Hamano

$ git log --author="Junio C Hamano"

$ git log   --author=gitster@pobox.com

我们甚至还可以通过'gmail.com'来搜索，结果就是 email主机地址为 gmail.com的贡献者所作提交的内容。$ git log --author=gmail --pretty=format:"%ae" | wc -l

 1348

$ git log --author=gmail --pretty=format:"%ae" | sort -u | wc -l

     113

从这两个命令执行之后的结果看到，Git源码项目有 113个 gmail账户的作者贡献的1348个补丁。有趣的是，没有一个作者使用 hotmail账户，但是有 81个补丁来自'.mil'（都出自一个人）。$ git log --author='\.mil' --pretty=format:"%ae" | wc -l

      81

查找提交信息

如果你对“提交信息”更感兴趣，你可以通过提交信息里面的某个字符串来查找相应的提交。例如，下面是搜索在提交信息中含有'c90'的所有提交内容。$ git log --grep='C90' --pretty=oneline

8c9e7947c2a76fb21bda11816c544d50e271156d http-push.c: squelch C90

warnings.

 

文件历史还有的时候，你希望查看某个指定文件的提交历史。譬如你希望查看'notes.c'文件每一次的提交历史，你可以运行：$ git log --pretty=oneline -- notes.c 

22a3d060937072b0f197a8084af879c753c68fe7 git-notes: fix printing

of multi-lin

2dd625d022074bb677bdd5caa5146cabaf726123 Speed up git notes

lookup

879ef2485d6ced20845ca626ecb45a9b65aa3a70 Introduce commit notes

你还可以对文件目录进行这样的操作，譬如你想查看't/lib-httpd'目录的提交历史：$ git log --pretty=oneline --all -- t/lib-httpd/

466ddf90c2f270b973d141f20e912f743743331c http-push: when making

directories, 

603fb1168218a813f1b0816b1208c5d0c92cf29d Avoid apache complaining

about lack 

faa4bc35a05ddb1822f3770cd8c51859e3b929ee http-push: add

regression tests

 

也可以加入多个查询项目，譬如要查看't/lib-httpd'目录或 notes.c文件的提交历史：$ git log --pretty=oneline -- t/lib-httpd/ notes.c

7b75b331f6744fbf953fe8913703378ef86a2189 Merge branch 'js/notes'

466ddf90c2f270b973d141f20e912f743743331c http-push: when making

directories, 

22a3d060937072b0f197a8084af879c753c68fe7 git-notes: fix printing

of multi-lin

2dd625d022074bb677bdd5caa5146cabaf726123 Speed up git notes

lookup

879ef2485d6ced20845ca626ecb45a9b65aa3a70 Introduce commit notes

603fb1168218a813f1b0816b1208c5d0c92cf29d Avoid apache complaining

about lack 

faa4bc35a05ddb1822f3770cd8c51859e3b929ee http-push: add

regression tests

 

其他选项很多时候想查看未合并的提交历史记录，所以你可以加上'--no-merges'选项$ git log --grep='C90' --pretty=oneline --no-merges

8c9e7947c2a76fb21bda11816c544d50e271156d http-push.c: squelch C90

warnings.

8f1d2e6f49ee51ac062ab38337a6a70dd1998def [PATCH] Compilation:

zero-length arr

01c6ad29bd1b647d4fd1acea54e374c740ec3c10 [PATCH] Fix strange

timezone handlin

还可以在查看日志命令最后加上-N来查看满足条件的最近的N条历史记录：$ git log --pretty=oneline --no-merges -5 

621f1b4bcf40f1469fc59202248df35619e33c82 GIT 1.6.2-rc0

7851386948dce72c739bcdfe08f069afe4f5ea45 emacs: Remove the no

longer maintain

5a7b3bf5275adf86fdd23f8824562b88c8a20e33 git.el: Add some notes

about Emacs v

6c4f70d5b2fb8f9275ca85e0927f00b8bc892819 git.el: Use integer

instead of chara

efd49f50fc087df2ad46f194ca848c5335f4cca9 git.el: Set a regexp for

paragraph-s

 

如果下面是我们的提交历史：$ git log --pretty=oneline --graph

* 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile

* 964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo

* 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme

* a5f4a0daa9b13bb85283461ddaba6e589e34ccb5 added cat-file

* 310154e3c7db47d8bac935c2c43aee6afac11aae updated README

formatting and adde

* f7f3f6dd8fd3fa40f052427c32785a0fa01aaa5f changed my name a bit

* 710f0f8d2cdf5af87033b9ec08859a505f9a6af5 added ls-files

* c110d7ff8cfb86fd5cce9a8aee462678dbb4ef9b made the ls-tree

function recursiv

* ce9b0d5551762048735dd67917046b44176317e0 limiting log to 30

我们希望只看到提交信息为'added Is-files'之后，'updated readme'之前的提交历史，我们可以这样指定查询：[master]$ git log --pretty=oneline 710f0f..8a5cbc

8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme

a5f4a0daa9b13bb85283461ddaba6e589e34ccb5 added cat-file

310154e3c7db47d8bac935c2c43aee6afac11aae updated README

formatting and added 

f7f3f6dd8fd3fa40f052427c32785a0fa01aaa5f changed my name a bit

如果你在查找一个分枝上的提交时，这样做非常管用。譬如，你目前在'master'分枝上，并且想查看'experiment'分枝上还没有合并的提交记录的话，可以这样：$ git log master..experiment --pretty=oneline

f6b98e46bdf64454d7c6ab76d617237118799d7b git-web--browse: Fix

check for /bin/

df487baa30924a36ade38ada4f77379236dcce0f Merge branch 'maint'

a9ee90d7ff9f3854b3096b4abbdc2013708704f5 completion: Get rid of

tabbed indent

cf9957875c3a27b6ae4593e1fa9d4dabbde68433 completion: Fix

GIT_PS1_SHOWDIRTYSTA

7e1100e9e939c9178b2aa3969349e9e8d34488bf gitweb: add $prevent_xss

option to p

这就告诉你，如果现在合并的话，那么所有列出的这些提交都会被合并。你也可以不写某一端的分枝名，git会判断你目前正在哪个分枝上，所以，如果你在master分枝上的话，下面的命令执行结果和上面的一样：$ git log ..experiment --pretty=oneline

如果你在 experiment分枝上，也想看到相同的信息，即还没有合并到master的提交，可以运行：$ git log master.. --pretty=oneline

 

这一节讲的都是很常用的命令，下一课将深入剖析这些内容，但是这一节课最关键的是记住这些命令和它的作用。

Git学习教程（七） Git差异比对2009-12-18 18:36:56标签：比对 git 差异 学习 教程原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://fsjoy.blog.51cto.com/318484/245465

第七课 Git差异比对

内容提要：显示项目的两个不同版本之间的差异，或者显示指定文件的不同之处 

在‘git日志’一课中，我们通过'git log -p'命令来显示每一次提交与其父节点提交内容之间快照的差异。这节课介绍的'diff'命令会实现类似的功能---用一种统一的格式来显示两个快照或文件之间的差异。这节课就向你展示如何使用 diff命令。查看变更还未载入(changed but unstaged)的文件比对最常见的一种情况是使用'git diff'查看工作目录中某个还未载入（stage）的文件的差异。实验方案：1.修改一下 simplegit.rb，添加一个方法2.然后在README文件中添加一个作者3.然后我们用'git add'命令把README文件载入(stage)

4.运行'git status'会显示README载入了，而 simplegit.rb只是修改了还未载入。$ vim lib/simplegit.rb

$ vim README

$ git add README

$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

# modified:   README

#

# Changed but not updated:

#   (use "git add <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

# modified:   lib/simplegit.rb

#

那么，我现在想查看一下对 simplegit.rb文件究竟做了什么改动？在我载入之前怎么查看这些改动的内容呢？答案是只需运行不带任何参数的'git diff'命令即可：$ git diff

diff --git a/lib/simplegit.rb b/lib/simplegit.rb

index dd5ecc4..8ac6604 100644

--- a/lib/simplegit.rb

+++ b/lib/simplegit.rb

@@ -25,6 +25,10 @@ class SimpleGit

     command("git log -n 25 #{treeish}")

   end

+  def log_single(branch = 'master')

+    command("git log --pretty=oneline #{branch}")

+  end

+

   def blame(path)

     command("git blame #{path}")

   end

这样就可以看到我添加到文件中的内容，现在我可以决定是不是要将其载入了。注意，README文件的修改并没有显示出来。查看载入（stage）而并未提交（commit）的变更为了查看载入（staged）而并未提交（not committed）的内容差异，可以使用'git diff

--stage'命令（在 git 1.6之前的版本中，使用'--cached'）$ git diff --staged

diff --git a/README b/README

index c526f88..879f0d4 100644

--- a/README

+++ b/README

@@ -8,3 +8,4 @@ It is an example for the Git Peepcode book that I'm

currently writin

 Author : Scott Chacon (schacon@gmail.com)

          Orange Peel Chacon (opchacon@gmail.com)

          Magnus O. Chacon (mchacon@gmail.com)

+         Josephine Chacon (jo.chacon@gmail.com)

适应情形：在运行 git commit（不带'-a'）之前，查看所有载入而未提交的变更内容。查看在最后一次提交之后的所有变更现在，如果你想查看最后一次提交之后工作目录中文件的变更，你可以在 git diff之后加一个HEAD来进行比对：$ git diff HEAD

diff --git a/README b/README

index c526f88..879f0d4 100644

--- a/README

+++ b/README

@@ -8,3 +8,4 @@ It is an example for the Git Peepcode book that

I'm currently writin

 Author : Scott Chacon (schacon@gmail.com)

          Orange Peel Chacon (opchacon@gmail.com)

          Magnus O. Chacon (mchacon@gmail.com)

+         Josephine Chacon (jo.chacon@gmail.com)

diff --git a/lib/simplegit.rb b/lib/simplegit.rb

index dd5ecc4..8ac6604 100644

--- a/lib/simplegit.rb

+++ b/lib/simplegit.rb

@@ -25,6 +25,10 @@ class SimpleGit

     command("git log -n 25 #{treeish}")

   end

+  def log_single(branch = 'master')

+    command("git log --pretty=oneline #{branch}")

+  end

+

   def blame(path)

     command("git blame #{path}")

   end

适用情形：在运行'git commit -a'之前。显示所有载入的和未载入的变更。 

在本教程的'intermediate'一课中会详细讲述HEAD在 git中的含义。在这里要注意的一点是，HEAD的含义跟 SVN中的HEAD含义大不相同，在 git中HEAD与你目前所处分枝的最后一次提交相关。与每个用户的本地仓库相关，在不同分枝间切换时它也会发生改变。上面是使用'diff'时最常用的三条命令。从一个特定点开始文件的修改情况这也是最常见的一个问题。譬如，如何查看创建 v1.6这个标签之后README文件所发生的修改呢，可以这样：

$ git diff v1.6.0 -- README 

diff --git a/README b/README

index 548142c..5fa41b7 100644

--- a/README

+++ b/README

@@ -24,7 +24,7 @@ It was originally written by Linus Torvalds

with help of a group o

 hackers around the net. It is currently maintained by Junio C

Hamano.

 Please read the file INSTALL for installation instructions.

-See Documentation/tutorial.txt to get started, then see

+See Documentation/gittutorial.txt to get started, then see

 Documentation/everyday.txt for a useful minimum set of commands,

 and "man git-commandname" for documentation of each command.

上面就显示出了工作目录中README文件的版本差异--如果你做了本地修改，载入或未载入，都会在这次比对中显示出来。两次提交的差异比对如果你想对两次快照做差异比对，也即项目的两个版本之间比对--直接在 git diff后跟上要比对的两个版本号即可：$ git diff v1.0 v1.1

如果这两个版本分别在两个目录中的话，直接运行 unix的'diff'工具进行比对也可以。

上节课在介绍 log命令时讲过格式化参数，譬如-stat，在这里也可以对 git diff命令加这样的参数，显示某些统计数，下面是显示 v1.6.1.1和 v1.6.1.2两个版本之间差异的统计数字：$ git diff v1.6.1.1 v1.6.1.2 --stat

 Documentation/RelNotes-1.6.1.2.txt |   39 +++++++++++++

 Documentation/config.txt           |    4 +-

 Documentation/git-ls-tree.txt      |    8 +++-

 GIT-VERSION-GEN                    |    2 +-

 RelNotes                           |    2 +-

 builtin-commit.c                   |    6 ++

 builtin-gc.c                       |    8 ++-

 builtin-grep.c                     |   15 +++++-

 builtin-log.c                      |   28 +++++++++-

 builtin-ls-tree.c                  |    7 ++-

 builtin-send-pack.c                |   43 +++++++--------

 diffcore-rename.c                  |    9 +++-

 git-sh-setup.sh                    |    2 +-

 sha1_file.c                        |    3 +-

 sha1_name.c                        |    2 +-

 t/t2300-cd-to-toplevel.sh          |    4 +-

 t/t4014-format-patch.sh            |   52 +++++++++++++++++-

 t/t5519-push-alternates.sh         |  106 ++++++++++++++++++++++

++++++++++++++

 t/t7002-grep.sh                    |    7 +++

 test-path-utils.c                  |    2 +-

 20 files changed, 306 insertions(+), 43 deletions(-)

还可以深入查看某个具体文件的变更比对：$ git diff v1.6.1.1 v1.6.1.2 -- sha1_file.c

diff --git a/sha1_file.c b/sha1_file.c

index 52d1ead..ce5ea12 100644

--- a/sha1_file.c

+++ b/sha1_file.c

@@ -2337,7 +2337,8 @@ static int create_tmpfile(char *buffer,

size_t bufsiz, const c

 static int write_loose_object(const unsigned char *sha1, char

*hdr, int hdrlen,

                              void *buf, unsigned long len,

time_t mtime)

 {

-       int fd, size, ret;

+       int fd, ret;

+       size_t size;

        unsigned char *compressed;

        z_stream stream;

        char *filename;

执行之后会显示 sha1_file.c文件在 v1.6.1.1和 v1.6.1.2两个版本之间的比对结果。在合并某分枝前查看变更内容这是个比较奇怪的问题，因为如果你开始是工作在一个主分枝上，而后生成了两个分支，如果直接对比快照的话，结果只会显示从一个状态到另一个状态的差异比对结果。举例来说，如果你创建了一个'dev'的分枝，进入这个分枝给 lib/simplegit.rb添加了一个函数，然后回到了'master'分枝，删除了README文件的一行，然后运行：$ git diff master dev

结果会显示你给某个文件中添加了方法，还往README文件添加了一行内容。为什么会这样？因为对'dev'分枝来说，README文件还是原样，而在'master'上，你已经删掉了一行，这样直接对两个快照进行对比就好似'dev'分枝添加了一行进去一样。你想查看的实际上是在创建 dev分枝之后在这条分枝上的差异对比，所以应该执行这样的命令：$ git diff master...dev

这就不会拿master分枝上最后一个快照和 dev分枝上最后一个快照进行比对--而是用dev与master所交的那个分歧点和现在的 dev分枝上最后一个快照进行比对。在我们这个例子中，这样比对的结果是显示对那个文件添加了一个函数。如果你目前正处在master

分枝上，你可以运行：$ git diff ...dev

跟上面的结果是一样的。所以，如果你想查看将要合并的某个分枝会有什么样的变化，可以执行：$ git diff ...(branch)

将 branch替换为你想要合并的分枝名即可。