课件下载地址：

作者回复: 👍

作者回复: 很好的问题！我们10号视频对象关系那一节提到blob，Git对于内容相同的文件只会存一个blob，不同的commit的区别是commit、tree和有差异的blob，多数未变更的文件对应的blob都是相同的，这么设计对于版本管理系统来说可以省很多存储空间。其次，Git还有增量存储的机制，我估计是对于差异很小的blob设计的吧。

作者回复: Google或者必应的国际版 里面搜索“git how to check whether blob content changed” --> 点击 “http://www-cs-students.stanford.edu/~blynn/gitmagic/ch08.html” ，web页面里面搜索“whether a file has changed” 。看来Git先把文件的大小、创建时间、最后修改时间信息放在index里面，只要把当前的状况和index的内容做比较，就能判断blob是否变更了。

作者回复: 只要git不报错，都行啊

作者回复: 好问题，稍等。不好意思，让你等了这么久。 https://github.com/gotgit/gotgit/blob/master/02-git-solo/030-head-master-commit-refs.rst 当年《Git权威指南》，现在作者开源了。这节的内容当下还是适用的

作者回复: 好问题。像GitLab这些平台，本身就会对git仓库做压缩等事务，如果你们仓库大是因为存放了大文件的话，建议找找GitLab LFS资料看看。 如果不是大文件引起仓库大，就是文件个数多，commit个数多引起仓库大，想让仓库变小的话，办法也有多种。比如从某个版本后新建git仓库，也可以清理不用的分支（从而删除只在该分支上的commit），还可以只保留主分支的commit。有空我帮你找找资料再交流吧。

作者回复: 换个思路想，如果我们自己是Linus，在设计版本管理工具的时候，会不会考虑把内容相同的文件当做一个对象来处理呢？还是说不同分支，即使内容相同也存为不同的对象？ Linus选择的是前者，甚至于不同的git仓库，只要内容相同的文件，其blob的HASH值也是相同的。大家可以做实验验证一下。

作者回复: 👍，理解到位

作者回复: git中的文件夹确实就是用tree组织的。从现有知识来看，可以把tree对应于文件夹对象。

作者回复: 不用担心的，找得回来的。如果删除的文件还没有生成commit，你用git status 看一下，它有说明教你怎么恢复文件的。 用 git reset HEAD -- 被删除的文件 ，这样试试看，能恢复不？