Git是Linus.Torvald为了管理Linux内核发起并开发的一个开源分布式版本控件系统（DVCS）。从2002年起，Linux 内核一直使用BitKeeper来进行版本管理，但是在2005年BitKeeper和Linux 内核开源社区的合作关系结束，BitKeeper再也不能免费使用了，这迫使Linus决定开发一个开源界自已的版本控制系统。

传统的SVN、CVS 等版本控制系统，只有一个仓库（repository)，用户必须要连上这个仓库才能开始提交；而Git之类的分布式版本控制系统（当然也还包括 BitKeeper、Mercurial等等），它的每个工作目录都包含一个完整的仓库，它们可以支持离线工作，先把工作提交到本地仓库后再提交上远程的服务器上的仓库里。分布式的处理也让开发更为便捷，开发人员可以很方便的在本地创建分支来进行日常开发，每个人的本地仓库都是平等且独立，不会因为你的本地提交而直接影响别人。

老实说，Git的速度是我用的版本控制系统中最快的（SVN Mercurial Git）。我这里说的速度，包括本地提交(commit)、本地签出(checkout)、提交到远程仓库(git push)和从远程仓库获取（git fetch ，git pull）；它的本地操作速度和本地文件系统在一个级别，远程仓库的操作速度和SFTP文件传输在一个级别。这当然和Git的内部实现机制有关，这里就不多展开了，有兴趣的朋友可以看一下这里：Git is the next Unix。

我们在学一门新的语言时，往往是从一个“hello world” 程序开始的，那么Git历程也就从一个“hello Git”开始吧。

在这里假设各位同学的电脑都装好了Git，如果没有装好，可以先看一下这里（安装Git）。当然，后面的章节我会专门讲安装可能会碰到的问题。

我们首先打开Git的命令行：windows下是点击“Git Bash 快捷方式”；Linux或是Unix like平台的话就直接打开命令行界面就可以了。

备注：$符号后面的字符串代表的是命令行输入；命令行输入后的以#开始的黑体字符串代表注释；其它的部分则是命令行输出。

我们先用建一个仓库吧：

$mkdir testGit #建立仓库目录
$cd testGit #进入仓库目录
$git init #这会在当前的目录下建一个仓库
Initialized empty Git repository in e:/doc/Git/test/testGit/.git/ 

好的，前面的三行命令就建立了一个本地的Git仓库。这个仓库现在是一个空的仓库。

我们在命令行下执行：

$ git status #查看当前仓库的状态
# On branch master (在master分支上) 
# 
# Initial commit 
# 
nothing to commit (create/copy files and use "git add" to track) 
(现在没有任何台被提交的文件，复制或创建新的文件，再用”git add” 命令添加到暂存区中) 
$ git log #查看当前仓库的历史日志
fatal: bad default revision 'HEAD'
(由于仓库里没有任提交在里面，所以它会报这个错。BTW: 这种提示是不是有点不友好呀：) ) 

现在就让我们在这个仓库里添加点内容吧。

$ echo “hello Git” > readme.txt #建立一个含有 hello Git 的文本文件
$ git add readme.txt #将readme.txt添加到暂存区中
$ git status #查看当前仓库的状态 
# On branch master 
# 
# Initial commit 
# 
# Changes to be committed:(暂存里下次将被提交的修改) 
# (use "git rm --cached <file>..." to unstage) 
# 
# new file: readme.txt 
# 

好的，文件即然被暂存到暂存区中，我们现在就可以把它提交到仓库里面去：）

$ git commit -m "project init" #将刚才的修改提交到本地仓库中 
[master (root-commit) 8223db3] project init 
1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 readme.txt 
$ git status 
# On branch master 
nothing to commit (working directory clean) 
(现在这个工作目录里没有什么要提交的东东，它是整洁的) 

现在你执行一下git log 命令就会看到刚才的提交记录

$ git log 
commit 8223db3b064a9826375041c8fea020cb2e3b17d1 
Author: liuhui998 <liuhui998@gmail.com> 
Date: Sat Jan 1 18:12:38 2011 +0800 
project init 

“8223db3b064a9826375041c8fea020cb2e3b17d1”这一串字符就是我们这次创建的提交的名字。看起来是不是很熟，如果经常用电驴的朋友就会发现它就是和电驴里内容标识符一样，都是SHA1串。Git通过对提交内容进行 SHA1 Hash运算，得到它们的SHA1串值，作为每个提交的唯一标识。根据一般的密码学原理来说，如果两个提交的内容不相同，那么它们的名字就不会相同；反之，如果它们的名字相同，就意味着它们的内容也相同。

现在我想改一下仓库里文件的内容，现提交到仓库中去

$ echo "Git is Cool" >> readme.txt #在文件的最后添加一行 
$ 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.txt 
# 
no changes added to commit (use "git add" and/or "git commit -a") 
(没有修改可以被提交，使用 “git add” 命令添加文件到暂存区，或是使用“git commit -a” 命令强制提交当前目录下的所有文件)

OK，即然我们修改了仓库里被提交的文件，那么我想看一下我们

到底改了哪些地方，再决定是否提交。

$ git diff #查看仓库里未暂存内容和仓库已提交内容的差异 
diff --git a/readme.txt b/readme.txt 
index 7b5bbd9..49ec0d6 100644 
--- a/readme.txt 
+++ b/readme.txt 
@@ -1 +1,2 @@ 
hello Git 
+Git is Cool 

很好，正如我们所愿，我们只是在readme.txt的最后一行添加了一行“Git is Cool”。

好的，我们现在再把 readme.txt放到暂存区里：

$ git add readme.txt

我们现在看一下仓库的状态：

$ git status 
# On branch master 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
# modified: readme.txt 
# 

可以提交了：

$ git commit -m "Git is Cool" 
[master 45ff891] Git is Cool 
1 files changed, 1 insertions(+), 0 deletions(-) 
(一个文件被修改，一行插入，零行删除) 

再看一下新的日志：

$ git log 
commit 45ff89198f08365bff32364034aed98126009e44 
Author: liuhui998 <liuhui998@gmail.com> 
Date: Sat Jan 1 18:17:07 2011 +0800 
Git is Cool 
commit 8223db3b064a9826375041c8fea020cb2e3b17d1 
Author: liuhui998 <liuhui998@gmail.com> 
Date: Sat Jan 1 18:12:38 2011 +0800 
project init 

“45ff89198f08365bff32364034aed98126009e44” 这个就是我们刚才提交修改时创建的提交。

大家这么一路看过来，是不是有点糊涂了。不过没有关系，如果你的电脑装了Git，那么你把上面的这些命令全部执行一下遍就会对它有感性的认识了。

下面的的章节，我会讲一下如何在windows和Linux安装配置Git，以及需要注意的问题：）

Git的安装和配置

各位同学，上回Git历险记（一）讲了一个 “hello Git” 的小故事。有的同学可能是玩过了其它分布式版本控制系统（DVCS），看完之后就触类旁通对Git就了然于胸了；也有的同学可能还如我当初入手Git一样，对它还是摸不着头脑。

从这一篇开始，我就将比较“啰嗦”的和大家一起从零开始经历Git使用的每一步，当然对我而言这也是一个重新认识Git的过程。

使用Git的第一步肯定是安装Git，因为在多数平台上Git是没有预装的。我平时主要的工作环境是windows和Linux（ubuntu），我想看这篇文章的同学多半也是在这两个平台下工作；下面我讲一下如何在这两个平台下安装和配置Git。

BTW:如果是苹果平台的用户的安装可以参看一下这里(1,2)，配置和命令行的使用与windows、Linux（*nix）平台差别不大。

Linux (*nix) 平台

Linus开发Git的最初目的就是为了开发Linux内核服务的，自然它对Linux的平台支持也是最棒的。在Linux下安装Git大约有几种方法：

从源代码开始(这种方法也适合于多数*nix平台)

从Git官网的下载页面下载它最新稳定版的源代码，就可以从源代码开始编译、安装：

$ wget http://kernel.org/pub/software/scm/git/git-1.7.3.5.tar.bz2
$ tar -xjvf git-1.7.3.5.tar.bz2
$ cd git-1.7.3.5
$ make prefix=/usr all ;# prefix设置你的Git安装目录
$ sudo make prefix=/usr install ;# 以root权限运行 

为了编译Git的源代码，我们还需要一些库: expat、curl、 zlib 和 openssl； 除了expat 外，其它的库可能在你的机器上都安装了。

使用安装包管理器（apt 或 yum）

在 fedora 等系统下用yum ：

$ yum install git-core

在debian, ubuntu等系统下用apt ：

$ apt-get install git-core

有时候，你系统里的安装包管理器出现了问题，或是要安装Git的机器不能上网、没有编译器的话，你可以从下面的站点去下载 “.deb” 或 “.rpm”的安装包：

• RPM Packages
• Stable Debs

Windows平台

windows平台有两个模拟*nix like运行环境的工具：cygwin，msys；Git在cygwin，msys下都有相应的移植版本。我个人觉得msys平台下的msysGit最好用，现在我在windows下也是用的这个版本。

很多同学可能要问，现在windows下有那多Git用户，为什么Git不直接出一个windows native版。俺当年翻看了一下Git的源代码，它里面使用了大量的*nix平台的native api，而这些api在windows下是没有的，所以必须要用cygwin、msys这样的一个中间层来满足软件移植的要求。

下面我“啰嗦”一下如何在windows下安装msysGit。

下载

到它的下载页面去下载一个最新的完整安装包，笔者在撰写本文时下载的是这个。

安装

安装的过程没有什么好说的，一般是开始安装后，一路的点击“下一步”。由于windows平台的换行符（CRLF）和Linux(*nix)平台的换行符（LF）不同，那么在windows下开发其它平台软件的朋友有一个地方要注意（见下图)：

在这里一最好选“Checkout as-is, commit as-is”这个选项，这样，Git就不会修改你代码的换行符风格。

以前有个朋友因为选错了这个选项，以致他在windows平台下的一签出（checkout）其它平台的代码，就会显示”已修改“（modified），不过后来可能msysGit也认识到这个问题了，就把默认选项改成了这个选项。

BTW: 其实前面两项也是有用的，如果对windows和Linux(*nix)平台如何处理换行符很熟悉的话，也可以尝试一下前面两个选项：）

配置Git

在Linux下和windows下配置Git的方法差不多，只是在Linux下，可以在命令行里直接使用git config进行配置, 而在windows下则要先打开“Git Bash”，进入msysGit命令行界面，再用git config命令进行相应的配置操作。

好了，前面安装好了Git，现在我们开始配置：

第一个需要配置的就是用户的用户名和email，因为这些内容会出现在你的每一个提交（commit）里面的，像下面这样：

$ git log #我们用git log查看当前仓库的提交（commit）日志
commit 71948005382ff8e02dd8d5e8d2b4834428eece24
Author: author <author@corpmail.com>
Date: Thu Jan 20 12:58:05 2011 +0800
Project init 

下面的这两行命令就是设置用户名和email：

$ git config --global user.name author #将用户名设为author
$ git config --global user.email author@corpmail.com #将用户邮箱设为author@corpmail.com 

Git的配置信息分为全局和项目两种，上面命令中带了“--global"参数，这就意味是在进行全局配置，它会影响本机上的每个一个Git项目。

大家看到，上面我们用的是@corpmail（公司邮箱）；但是有时候我们可能也参与了一些开源项目，那么就需要新的用户名和自己的私人邮箱，Git 可以为每个项目设定不同的配置信息。

在命令行环境，进入Git项目所在目录，执行下面的命令：

$ git config　user.name nickname#将用户名设为nickname
$ git config　user.email nickname@gmail.com #将用户邮箱设为nickname@gmail.com 

Git的设计哲学和Linux（*nix）一样，尽量的使用“文本化”（Textuality）；它里面尽量用文本化的形式存储信息，对于配置信息也更是如此，用户的这些配置信息全部是存储在文本文件中。Git的全局配置文件是存放在"~/.gitconfig"（用户目录下的.gitconfig）文件中：

我们用cat、head命令查看全局配置信息文件，并假设相关配置信息存储在文件的前3行（当然也有可能不在前3行，这里只是为了方便表示）

$ cat ~/.gitconfig | head -3 
[user]
name = author
email = author@corpmail.com 

而项目配置文件是存放在Git项目所在目录的".git/config"文件中，这里也像上面一样用cat、head命令查看一下：

$ cat .git/config | head -3
[user]
name = nickname 

如果大家对于Git熟悉后，可以直修改”~/.gitconfig”,”.git/config”这两个文件进行配置。

Git里还有很多可以配置的地方，大家可以参考一下git config 和 定制git。

这一篇写起来有点平淡无奇，但这是一个Git用户迈出的第一步。后面我还会有一系列的文章出来，都是我个人使用过程中的感悟。

有朋友问我：“为什么把文章叫作：‘Git历险记’”。这是因为在使用Git的历程中，我碰到过N多的问题；同时也觉得它有点小复杂。但是当这些问题解开后，就有时不得不赞叹它设计的巧妙之处。

如果大家对于我的文章有什么问题和建议，欢迎给我写邮件：

之前我建立了一个 git中文用户组 ，如果大家在使用Git的过程中碰到什么麻烦事，欢迎你在这个用户组里提问。

创建一个自己的本地仓库

v":* {behavior:url(#default#VML);} o":* {behavior:url(#default#VML);} w":* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} st1":*{behavior:url(#ieooui) }

如果我们要把一个项目加入到Git的版本管理中，可以在项目所在的目录用git init命令建立一个空的本地仓库，然后再用git add命令把它们都加入到Git本地仓库的暂存区（stage or index）中，最后再用git commit命令提交到本地仓库里。

创建一个新的项目目录，并生成一些简单的文件内容：

$ mkdir test_proj
$ cd test_proj
$ echo “hello,world” > readme.txt 

在项目目录创建新的本地仓库，并把项目里的所有文件全部添加、提交到本地仓库中去：

$ git init #在当前的目录下创建一个新的空的本地仓库
Initialized empty Git repository in /home/user/test_proj/.git/
$ git add . #把前目录下的所有文件全部添加到暂存区
$ git commit -m 'project init' #创建提交
[master (root-commit) b36a785] project init
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 readme.txt

Git目录的结构

git init命令在项目的顶层目录中建了一个名为：“.git”的目录，它的别名是 “Git目录”（Git directory）。这时”Git目录”中虽然有一些文件，但是没有任何提交（commit）在里面，所以我们叫它是空仓库（empty Git repository）。

和 SVN不同，一个Git项目一般只在项目的根目录下建一个“.git”目录，而SVN则会在项目的每一个目录下建一个”.svn”目录；这也我喜欢Git的原因之一：）

Git把所有的历史提交信息全部存储在“Git目录”里，它就是一个Git项目的仓库；你对本地的源代码进行编辑修改后创建的提交也都会先保存在这里面，然后再推送到远端的服务器。当我们我把项目目录和“Git目录”一起拷到其它电脑里，它能马上正常的工作（所有的提交信息全都保存在Git目录 里）；甚至可以只把“Git目录”拷走也行，但是要再签出（checkout）一次。

Git为了 调试的方便，它可以指定项目的Git目录的位置。有两种办法：一是设置“GIT_DIR”环境变量，二是在命令行里设定“--git-dir--git-dir”参数指定它的位置，大家可以看一下这里(git(1) Manual Page)。

庖丁解牛

前面的这些东东我在第一篇里也大概的讲过一些，但是今天我们想不但要开动这辆叫“Git”的跑车，还想看看它里面有些什么样的零件，是怎么构成的。

OK，我们来看看“test_proj”项目里的“Git目录”的结构：

$cd test_proj/.git

$ ls | more

branches/ # 新版的Git已经不再使用这个目录，所以大家看到它 #一般会是空的

COMMIT_EDITMSG # 保存着上一次提交时的注释信息

config # 项目的配置信息

description # 项目的描述信息

HEAD # 项目当前在哪个分支的信息

hooks/ # 默认的“hooks” 脚本文件

index # 索引文件，git add 后把要添加的项暂存到这里

info/ # 里面有一个exclude文件，指定本项目要忽略的文件 #，看一下这里

logs/ # 各个refs的历史信息

objects/ # 这个目录非常重要，里面存储都是Git的数据对象

# 包括：提交(commits), 树对象(trees)，二进制对象 #（blobs）,标签对象（tags）。

#不明白没有关系，后面会讲的。

refs/ # 标识着你的每个分支指向哪个提交（commit）。

我先用git log命令来看一下这个Git项目里有哪些提交：

$ git log
commit 58b53cfe12a9625865159b6fcf2738b2f6774844
Author: liuhui998 <liuhui998@nospam.com>
Date: Sat Feb 19 18:10:08 2011 +0800
project init

大家可以看到目前只有一个提交（commit）对象，而它的名字就 是：”58b53cfe12a9625865159b6fcf2738b2f6774844”。这个名字就是对象内容的一个SHA签名串值，只要对象里面的内容不同，那么我们就可以认为对象的名字不会相同，反之也成立。我在使用时一般不用把这个40个字符输全，只要把前面的5~8个字符输完就可以（前提是 和其它的对象名不冲突）。为了方便表示，在不影响表达的情况下，我会只写SHA串值的前6个字符。

我们可以用git cat-file来看一下这个提交里的内容是什么:

$ git cat-file -p 58b53c 
tree 2bb9f0c9dc5caa1fb10f9e0ccbb3a7003c8a0e13
author liuhui998 <liuhui998@nospam.com> 1298110208 +0800
committer liuhui998 <liuhui998@nospam.com> 1298110208 +0800
project init 

大家可以看到：提交“58b53c” 是引用一个名为“2bb9f0”的树对象（tree）。一个树对象（tree）可以引用一个或多个二进制对象（blob）, 每个二进制对象都对应一个文件。 更进一步, 树对象也可以引用其他的树对象，从而构成一个目录层次结构。我们再看一下这个树对象（tree）里面有什么东东：

$ git cat-file -p 2bb9f0

100644 blob 2d832d9044c698081e59c322d5a2a459da546469 readme.txt

不难看出，2bb9f0”这个树对象（tree）包括了了一个二进制对象（blob），对应于我们在前面创建的那个叫 ”readme.txt”的文件。现在我们来看看这个”blob”里的数据是不是和前面的提交的内容一致：

$ git cat-file -p 2d832d

hello,world

哈哈，熟悉的“hello,world”又回来了。

想不想看看提交对象、树对象和二进制对象是怎么在”Git目录“中存储的；没有问题，执行下面的命令，看看”.git/objects”目录里的内容：

$ find .git/objects
.git/objects
.git/objects/2b
.git/objects/2b/b9f0c9dc5caa1fb10f9e0ccbb3a7003c8a0e13
.git/objects/2d
.git/objects/2d/832d9044c698081e59c322d5a2a459da546469
.git/objects/58
.git/objects/58/b53cfe12a9625865159b6fcf2738b2f6774844
.git/objects/info
.git/objects/pack

如果大家仔细看上面命令执行结果中的粗体字，所有的对象都使用SHA签名串值作为索引存储在”.git/objects”目录之下；SHA串的前两个字符作为目录名，后面的38个字符作为文件名。

这些文件的内容其实是压缩的数据外加一个标注类型和长度的头。类型可以是提交对象（commit）、二进制对象（blob）、 树对象（tree）或者标签对象（tag）。

如何clone一个远程项目

我身边的很多朋友是因为要得到某个开源项目的代码，所以才开始学习使用Git。而获取一个项目的代码的一般的做法就是用git clone命令进行直接复制。

例如，有些朋友可能想看一下最新的linux内核源代码，当我们打开它的网站时，发现有如下面的一段提示：

URL
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

URL下面的三行字符串表示三个地址，我们可以通过这三个地址得到同样的一份Linux内核源代码。

也就是说下面这三条命令最终得到的是同一份源代码：

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git cone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

我们先来看一下URL，git://、http://、https://这些代表是传输git仓库的协议形式，而“git.kernel.org“则代表了Git仓库存储的服务器名字（域名），“/pub/scm/linux/kernel/git/torvalds/linux-2.6.git” 则代表了Git仓库在服务器上位置。

Git 仓库除了可以通过上面的git、http、https协议传输外还可以通过ssh、ftp(s)、rsync等协议来传输。git clone的本质就是把“Git目录”里面的内容拷贝过来，大家想想看，一般的“Git目录”里有成千上万的各种对象（提交对象，树对象，二进制对象......)，如果逐一复制的话，其效率就可想而知。

如果通过git、ssh协议传输，服务器端会在传输前把需要传输的各种对象先打好包再进行传输；而http（s）协议则会反复请求要传输的不同对 象。如果仓库里面的提交不多的话，前者和后者的效率相差不多；但是若仓库里有很多提交的话，git、ssh协议进行传输则会更有效率。

不过现在Git对http（s）协议传输Git仓库做了一定的优化，http（s）传输现在也能达到ssh协议的效率，有兴趣的朋友可以看一下这里（Smart HTTP Transport）。

好的，现在我们执行了下面这条命令，把linux-2.6的最新版源代码clone下来：

$cd ~/
$mkdir temp
$git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Initialized empty Git repository in /home/liuhui/temp/linux-2.6/.git/
remote: Counting objects: 1889189, done.
remote: Compressing objects: 100% (303141/303141), done.
Receiving objects: 100% (1889189/1889189), 385.03 MiB | 1.64 MiB/s, done.
remote: Total 1889189 (delta 1570491), reused 1887756 (delta 1569178)
Resolving deltas: 100% (1570491/1570491), done.
Checking out files: 100% (35867/35867), done.

当我们执行了“git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git”这条命令后大家可以看到这条输出：

Initialized empty Git repository in /home/user/temp/linux-2.6/.git/

这就是意味着我们在本地先建了一个“linux-2.6”目录，然后在这个目录建了一个空的Git本地仓库（Git目录）；里面将会存储从网上拉下来的历史提交。

下面两条输入代表服务器现在调用 git-pack-objects 对它的仓库进行打包和压缩：

remote: Counting objects: 1888686, done

remote: Compressing objects: 100% (302932/302932), done.

然后客户端接收服务器端发过送过来的数据：

Receiving objects: 100% (1889189/1889189), 385.03 MiB | 1.64 MiB/s, done.

在我们执行完上面的clone linux-2.6代码的的操作后，Git会从“Git目录”里把最新的代码到签出（checkout）到“linux-2.6”这个目录里面。我们一般把本地的“linux-2.6”这个目录叫做”工作目录“（work directory），它里面保存着你从其它地方clone（or checkout）过来的代码。当你在项目的不同分支间切换时，“工作目录”中的文件可能会被替换或者删除；“工作目录”只是保存着当前的工作，你可以修 改里面文件的内容直到下次提交为止。

大家还记得前面的“庖丁解牛”吗，是不是觉得只杀一头叫“hello,world”的小牛太不过瘾了。没有问题，拿起前面的那把小刀，来剖析一下现在躺在你硬盘里这头叫“linux-2.6”大牛看看，我想一定很好玩。

索引与提交的幕后故事

不一样的索引

我想如果看过《Git历险记》的前面三篇文章的朋友可能已经知道怎么用git add，git commit这两个命令了；知道它们一个是把文件暂存到索引中为下一次提交做准备，一个创建新的提交（commit）。但是它们台前幕后的一些有趣的细节大家不一定知晓，请允许我一一道来。

Git 索引是一个在你的工作目录（working tree）和项目仓库间的暂存区域(staging area)。有了它, 你可以把许多内容的修改一起提交(commit)。 如果你创建了一个提交(commit)，那么提交的一般是暂存区里的内容, 而不是工作目录中的内容。

一个Git项目中文件的状态大概分成下面的两大类，而第二大类又分为三小类：

• 未被跟踪的文件（untracked file）
• 已被跟踪的文件（tracked file）

1. 被修改但未被暂存的文件（changed but not updated或modified）
2. 已暂存可以被提交的文件（changes to be committed 或staged）
3. 自上次提交以来，未修改的文件(clean 或 unmodified)

看到上面的这么多的规则，大家早就头大了吧。老办法，我们建一个Git测试项目来试验一下：

我们先来建一个空的项目：

$rm -rf stage_proj
$mkdir stage_proj
$cd stage_proj
$git init
Initialized empty Git repository in /home/test/work/test_stage_proj/.git/ 

我们还创建一个内容是“hello, world”的文件：

$echo "hello,world" > readme.txt
现在来看一下当前工作目录的状态，大家可以看到“readme.txt”处于未被跟踪的状态（untracked file）：

$git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   readme.txt
nothing added to commit but untracked files present (use "git add" to track) 

把“readme.txt"加到暂存区： $git add readme.txt

现在再看一下当前工作目录的状态：

$git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   new file:   readme.txt
# 

可以看到现在"readme.txt"的状态变成了已暂存可以被提交（changes to be committed），这意味着我们下一步可以直接执行“git commit“把这个文件提交到本地的仓库里去了。

暂存区（staging area）一般存放在“git目录“下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。索引是一个二进制格式的文件，里面存放了与当前暂存内容相关的信息，包括暂存的文件名、文件内容的SHA1哈希串值和文件访问权限，整个索引文件的内容以暂存的文件名进行排序保存的。

但是我不想马上就把文件提交，我想看一下暂存区（staging area）里的内容，我们执行git ls-files命令看一下：

$git ls-files --stage

100644 2d832d9044c698081e59c322d5a2a459da546469 0 readme.txt

我们如果有看过上一篇文章里的"庖丁解牛", 你会发现“git目录“里多出了”.git/objects/2d/832d9044c698081e59c322d5a2a459da546469”这么一个文件，再执行“git cat-file -p 2d832d” 的话，就可以看到里面的内容正是“hello,world"。Git在把一个文件添加暂存区时，不但把它在索引文件(.git/index)里挂了号，而且把它的内容先保存到了“git目录“里面去了。

如果我们执行”git add“命令时不小心把不需要的文件也加入到暂存区中话，可以执行“git rm --cached filename" 来把误添加的文件从暂存区中移除。

现在我们先在"readme.txt"文件上做一些修改后：

$echo "hello,world2" >> readme.txt

再来看一下暂存区的变化:

$git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   new file:   readme.txt
#
# 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.txt
# 

大家可以看到命令输出里多了一块内容：“changed but not updated ...... modified: readme.txt”。大家可能会觉得很奇怪，我前面不是把"readme.txt"这个文件给添加到暂存区里去了吗，这里怎么又提示我未添加到暂存区（changed but not updated）呢，是不是Git搞错了呀。

Git 没有错，每次执行“git add”添加文件到暂存区时，它都会把文件内容进行SHA1哈希运算，在索引文件中新加一项，再把文件内容存放到本地的“git目录“里。如果在上次执行 “git add”之后再对文件的内容进行了修改，那么在执行“git status”命令时，Git会对文件内容进行SHA1哈希运算就会发现文件又被修改了，这时“readme.txt“就同时呈现了两个状态：被修改但未被暂存的文件（changed but not updated），已暂存可以被提交的文件（changes to be committed）。如果我们这时提交的话，就是只会提交第一次“git add"所以暂存的文件内容。

我现在对于“hello,world2"的这个修改不是很满意，想要撤消这个修改，可以执行git checkout这个命令：

$git checkout -- readme.txt

现在再来看一下仓库里工作目录的状态：

$git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#   new file:   readme.txt
# 

好的，现在项目恢复到我想要的状态了，下面我就用git commit 命令把这个修改提交了吧：

$git commit -m "project init"
[master (root-commit) 6cdae57] project init   1 files changed, 1 insertions(+), 0 deletions(-)    create mode
 100644 readme.txt

现在我们再来看一下工作目录的状态：

$git status
# On branch master
nothing to commit (working directory clean) 

大家可以看到“nothing to commit (working directory clean)”；如果一个工作树（working tree）中所有的修改都已提交到了当前分支里（current head），那么就说它是干净的（clean），反之它就是脏的(dirty)。

SHA1值内容寻址

正如Git is the next Unix 一文中所说的一样，Git是一种全新的使用数据的方式（Git is a totally new way to operate on data）。Git把它所管理的所有对象（blob，tree，commit，tag……），全部根据它们的内容生成SHA1哈希串值作为对象名；根据目前的数学知识，如果两块数据的SHA1哈希串值相等，那么我们就可以认为这两块数据是相同 的。这样会带来的几个好处：

Git只要比较对象名，就可以很快的判断两个对象的内容是否相同。

因为在每个仓库（repository）的“对象名”的计算方法都完全一样，如果同样的内容存在两个不同的仓库中，就会存在相同的“对象名”。

Git还可以通过检查对象内容的SHA1的哈希值和“对象名”是否匹配，来判断对象内容是否正确。

我们通过下面的例子，来验证上面所说的是否属实。现在创建一个和“readme.txt“内容完全相同的文件”readme2.txt“，然后再把它提交到本地仓库中：

$echo "hello,world" > readme2.txt
$git add readme2.txt
$git commit -m "add new file: readme2.txt"
[master 6200c2c] add new file: readme2.txt
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 readme2.txt 

下面的这条很复杂的命令是查看当前的提交（HEAD）所包含的blob对象：

$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p
100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme.txt
100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme2.txt 

我们再来看看上一次提交（HEAD^）所包含的blob对象：

$git cat-file -p HEAD^ | head -n 1 | cut -b6-15 | xargs git cat-file -p
100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme.txt 

很明显大家看到尽管当前的提交比前一次多了一个文件，但是它们之间却是在共用同一个blob对象：“2d832d9”。

No delta, just snapshot

Git 与大部分你熟悉的版本控制系统，如Subversion、CVS、Perforce 之间的差别是很大的。传统系统使用的是： “增量文件系统” （Delta Storage systems），它们存储是每次提交之间的差异。而Git正好与之相反，它是保存的是每次提交的完整内容（snapshot）；它会在提交前根据要提交的内容求SHA1哈希串值作为对象名，看仓库内是否有相同的对象，如果没有就将在“.git/objects"目录创建对应的对象，如果有就会重用已有的对象，以节约空间。

下面我们来试验一下Git是否真的是以“snapshot”方式保存提交的内容。

先修改一下"readme.txt"，给里面加点内容，再把它暂存，最后提交到本地仓库中：

$echo "hello,world2" >> readme.txt
$git add readme.txt
$git commit -m "add new content for readme.txt"
[master c26c2e7] add new content for readme.txt   1 files changed, 1 insertions(+), 0 deletions(-)

我们现在看看当前版本所包含的blob对象有哪些：

$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p
100644 blob 2e4e85a61968db0c9ac294f76de70575a62822e1    readme.txt
100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme2.txt

从上面的命令输出，我们可以看到"readme.txt"已经对应了一个新的blob对象：“2e4e85a”，而之前版本的"readme.txt“对应的blob对象是：“2d832d9”。下面我们再来看一看这两个”blob“里面的内容和我们的预期是否相同：

$git cat-file -p 2e4e85a
hello,world
hello,world2
$git cat-file -p 2d832d9
hello,world

大家可以看到，每一次提交的文件内容还是全部保存的（snapshot）。

小结

Git内在机制和其它传统的版本控制系统（VCS）间存在本质的差异，所以Git的里"add"操作的含义和其它VCS存在差别也不足为奇，“git add“不但能把未跟踪的文件（untracked file）添加到版本控制之下，也可以把修改了的文章暂存到索引中。

同时，由于采用“SHA1哈希串值内容寻值“和”快照存储（snapshot）“，让Git成为一个速度非常非常快的版本控制系统（VCS）。