在上一篇文章中，我们解释了Git的数据模型。在这一篇文章，我们来看看Git另一个重要的方面：index。Index空间，也叫做stage空间，或者cache空间，集中了很多人对Git的误解。在这篇文章里，让我来尝试解开大家关于这方面的疑惑。
之前的我也对这部分有不少误解。我曾经以为，当你新checkout一个commit以后，你的index将是一片空白。然后你通过git add往index添加需要更新的文件。当你commit以后，你的新修改文件会被加入到Git数据库，然后你的index又会回到一片空白的状态。
我的理解实际上包含了几个错误的地方：
-
Index并不是临时存放新文件的地方 - 新文件并不是在
git commit的时候才被加入到Git的数据库。实际上在git add的时候就已经被加入到数据库里了。 -
Index包含的并不是当前commit和新commit的diff
为了纠正这些错误观念，我们就要研究一下index里面到底存放着什么信息。我们可以通过查看./.git/index这个文件来得到答案。让我们继续使用上一篇文章的例子：
$ git checkout master
$ git ls-files --stage
100644 bf97e71de76bcff2bd8aba44710aa5e665eacb99 0 dir/inside.txt
100644 8231f0fdc862f06b2bd7b7bfd2f42082d3086b71 0 index.txt
上面的命令列出index中存放的信息。其中我们看到，即使我们是新checkout一个branch，index也不是空白的。它目前有两个条目，每个条目分别指向一个blob对象，而且还包含该blob对象所对应的文件的路径（分别是dir/inside.txt和index.txt）。而且这两个blob对象对应的都是当前commit中的文件版本。
让我们现在来做点小试验。让我们再次修改index.txt并添加到index中：
$ echo "version 3" > index.txt
$ git add index.txt
$ git ls-files --stage
100644 bf97e71de76bcff2bd8aba44710aa5e665eacb99 0 dir/inside.txt
100644 cd80567970da17e3c5d718e5b3db8700dbf320bf 0 index.txt
其实严格来说，“把index.txt添加到index中”这个表述并不准确。因为实际上我们看到的是，当我们执行git add时，新的index.txt已经被作为一个新的blob对象添加到了Git数据库中了，而并不是被添加到index中。Git只是更新了index中这个文件的指针来指向新版本的blob对象。如果我们此时执行git commit，那么，Git将会基于index里面所指向的这些blob对象以及他们对应的路径来生成tree对象，最终生成commit对象（下图）。也就是说，实际上index空间是新的commit的一个写照（snapshot）。
如果我们真正地明白这一点，那么很多本来觉得不自然的操作都显得理所应当了。例如，如果我们想让Git不再追踪一个文件，那么我们该怎么做呢？每当想到index是新commit的写照，那么我们就应该想到要移除index里面关于这个文件的条目。例如在我们的例子中，如果我想停止跟踪dir/inside.txt：
$ git rm --cache dir/inside.txt
$ git ls-files --stage
100644 cd80567970da17e3c5d718e5b3db8700dbf320bf 0 index.txt
又例如，我们有如下的历史：
HEAD → commit 5 → commit 4 → commit 3 → commit 2 → commit 1
如果我们想要合并commit 5, commit 4和commit 3，其中一种简单的方法就是使用git reset --soft如下：
$ git reset --soft [commit 2]
$ git commit -m "commit 6"
这样会得到以下结果：
HEAD → commit 6 → commit 2 → commit 1
原因就是，git reset --soft只把HEAD移到了commit 2，index并没有变化，所以新执行的commit是基于commit 2的（因为HEAD指向commit 2），但却会保留commit 5的内容。
解释了那么多，其实我想说的是，理解index的工作原理有助于我们自主去想解决的办法，而不是生搬硬套网上搜来的解决方法，是提高水平的一大重要途径。
