• 欢迎访问 winrains 的个人网站!
  • 本网站主要从互联网整理和收集了与Java、网络安全、Linux等技术相关的文章,供学习和研究使用。如有侵权,请留言告知,谢谢!

简单易懂理解Git的工作原理(2):Index空间

Git winrains 来源:Jo的工作笔记 12个月前 (11-09) 62次浏览
上一篇文章中,我们解释了Git的数据模型。在这一篇文章,我们来看看Git另一个重要的方面:indexIndex空间,也叫做stage空间,或者cache空间,集中了很多人对Git的误解。在这篇文章里,让我来尝试解开大家关于这方面的疑惑。
之前的我也对这部分有不少误解。我曾经以为,当你新checkout一个commit以后,你的index将是一片空白。然后你通过git addindex添加需要更新的文件。当你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.txtindex.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)

从index空间生成tree和commit对象

如果我们真正地明白这一点,那么很多本来觉得不自然的操作都显得理所应当了。例如,如果我们想让Git不再追踪一个文件,那么我们该怎么做呢?每当想到index是新commit的写照,那么我们就应该想到要移除index里面关于这个文件的条目。例如在我们的例子中,如果我想停止跟踪dir/inside.txt

$ git rm --cache dir/inside.txt
$ git ls-files --stage
100644 cd80567970da17e3c5d718e5b3db8700dbf320bf 0       index.txt

又例如,我们有如下的历史:
HEADcommit 5commit 4commit 3commit 2commit 1
如果我们想要合并commit 5, commit 4commit 3,其中一种简单的方法就是使用git reset --soft如下:

$ git reset --soft [commit 2]
$ git commit -m "commit 6"

这样会得到以下结果:
HEADcommit 6commit 2commit 1
原因就是,git reset --soft只把HEAD移到了commit 2,index并没有变化,所以新执行的commit是基于commit 2的(因为HEAD指向commit 2),但却会保留commit 5的内容。
解释了那么多,其实我想说的是,理解index的工作原理有助于我们自主去想解决的办法,而不是生搬硬套网上搜来的解决方法,是提高水平的一大重要途径。

作者:Jo的工作笔记

来源:https://www.jianshu.com/p/6bb76450d763


版权声明:文末如注明作者和来源,则表示本文系转载,版权为原作者所有 | 本文如有侵权,请及时联系,承诺在收到消息后第一时间删除 | 如转载本文,请注明原文链接。
喜欢 (1)