5.1、概述
每一次提交，Git 都会生成相关的版本号；每个版本号由 40 位 16 进制的数字组成。
这 40 位 16 进制的数字，是根据提交的内容，通过 SHA-1 算法计算出来的。
版本号具体还分为两部分，前 2 位是目录名，后 38 位是文件名。
5.2、文件操作
5.2.1、初始化本地库
如上图所示，刚创建的 Git 本地仓库没有提交信息，也没有版本号。
5.2.2、新增文件并提交
如上图所示，新增文件并提交后，通过 git reflog 命令可以查到对应的（精简）提交版本号：7896eb8
注意：本文使用精简的版本号演示，需要查看完整的版本号，请参考3.9.2节
5.2.3、根据版本号查找第一次提交的文件
因为版本号的前 2 位是目录名，后 38 位是文件名；所以可以快速定位出文件所在的位置。
如上图所示，直接打开文件时，内容是一堆乱码。
git cat-file -p 版本号
如上图所示，使用命令行指令才能读取版本号对应的文件内容。
可以看到，该文件内容并没有提交的文件的内容信息，但有另一个版本号。
如上图所示，读取上文发现的新版本号，还是没有提交的文件的内容信息，但又有新的版本号，而且对应提交的文件的名称。
如上图所示，读取上文发现的新版本号，可以看到了提交的文件的内容信息。
5.2.4、第一次提交的版本号图解
如上图所示，提交日志中的版本号所对应的文件，包含的内容是状态信息的版本号；
状态信息的版本号所对应的文件，包含的内容是本次提交版本的全部文件的版本号。
5.2.5、修改文件并提交
如上图所示，修改文件并提交后，通过 git reflog 命令可以查到对应的（精简）提交版本号：774e05f
5.2.6、根据版本号查找第二次提交的文件
如上图所示，根据第二次提交的版本号，可以查出本次提交的状态信息的版本号（tree）和上一次（即第一次）提交的版本号（parent）。
如上图所示，根据状态信息的版本号，可以查出本次提交版本的全部文件的版本号。
注意：修改后的a.txt文件的版本号已经变了，没有修改的b.txt文件的版本号和原来的一样。
如上图所示，修改后的a.txt文件的内容已经从“111”变为“333”了，没有修改的b.txt文件的内容还是原来的“222”。
5.2.7、第二次提交的版本号图解
如上图所示，所谓的修改文件，实质是新增了一个版本号不同但名称相同的文件，然后再新增一个状态版本用来记录新的文件版本号列表。
实际上，原来的文件还存在，这也是为什么能实现版本回退（穿梭）的原因。
5.2.8、删除文件并提交
如上图所示，删除文件并提交后，通过 git reflog 命令可以查到对应的（精简）提交版本号：a140418
5.2.9、根据版本号查找第三次提交的文件
如上图所示，根据第三次提交的版本号，可以查出本次提交的状态信息的版本号（tree）和上一次（即第二次）提交的版本号（parent）。
如上图所示，根据状态信息的版本号，可以查出本次提交版本的全部文件的版本号。
注意：已删除的b.txt文件的版本号已经没了，没删除的a.txt文件的版本号还在。
5.2.10、第三次提交的版本号图解
如上图所示，所谓的删除文件，实质是新增一个状态版本用来记录新的文件版本号列表。
实际上，原来的文件还存在，这也是为什么能实现版本回退（穿梭）的原因。
5.3、分支操作
5.3.1、HEAD文件
HEAD文件中，记录了当前分支版本文件（本例为 master 分支）的路径。
5.3.2、master分支版本文件
master分支版本文件中，记录了该分支的最新提交版本号。
5.3.3、master分支版本图解
5.3.4、创建新分支user
如上图所示，创建新分支user后，也多了一个分支版本文件user。
如上图所示，新创建的user分支版本文件中记录的该分支的最新提交版本号，和master分支版本文件记录的别无二致。
5.3.5、新创建的user分支版本图解
5.3.6、切换到user新分支
如上图所示，切换到user分支后，HEAD文件中记录的当前分支版本文件的路径是user分支版本文件的路径。
5.3.7、切换后的user分支版本图解
5.3.8、user分支新增文件并提交
如上图所示，user分支新增文件并提交后，user分支版本文件中记录的该分支的最新提交版本号，和master分支版本文件记录的不一样了。
5.3.9、新增文件后的user分支版本图解
5.3.10、切换回master分支
如上图所示，切换回master分支后，HEAD文件中记录的当前分支版本文件的路径是master分支版本文件的路径。
此外，master分支的工作目录中，并没有显示在user分支时新增的c.txt文件，说明在user分支的操作不会影响到master分支。
5.3.11、切换回的master分支版本图解
