关于Git的暂存区这个概念的理解.

Git中的暂存区成为stage或者是index.可以理解成一个"提交任务".Git暂存区是Git最成功的设计之一,但是也是最难理解的.

暂存区是一个介于工作区和版本库的中间状态.当执行提交的时候,实际上是将暂存区的内容提交到版本库中.

而且Git的很多命令都会涉及暂存区的概念.例如 git diff命令.

(什么是HEAD,什么是master,为什么他们两者可以相互替换使用,为什么Git中的很多对象(如提交树,文件内容等)都用40位的SHA1哈希值来表示?)

在版本库中 .git 目录中有一个index文件.需要运行git diff命令才能看到index文件的日期时间戳的变化.

其具体操作步骤如下:

1.首先执行git checkout命令,撤销工作区中welcome.txt文件sang

>>>>>>>>>>>>>未完待续>>>>>>>>

关于暂存状态:

绝对文件的四种状态:

>>>>>>>>>>>>>>>>未完待续>>>>>>>>>>>>>>>>>>>>>>>>>>

关于 $ git stash  命令

git stash 就用于保存当前工作进度的.

一开始运行git status 一些未提交的改动都存在,但是运行完 git stash之后,再查看工作区状态 git status ,会看见工作区尚未提交的改动(包括暂存区的改动)全都不见了.

因为执行了git stash命令来将工作区和暂存区的改动全部封存起来,所以执行下面的命令会看到工作区和暂存区没有改动

(-s 是精简输出simple , -b是同时显示出当前工作分支的名称,branch)

git branch 是分支管理的主要命令.也可以显示当前的工作分支.

在master分支名称前的星号表明这个分支是当前工作分支.

现在连续执行下面的三个命令会看到相同的输出:

以上三个具有相同的输出:也就是说当前版本库中,HEAD,master和 refs/heads/master具有相同的指向.

现在当版本库(.git文件夹)中看一下究竟怎么回事.

找到了4个文件,其中在.git/logs目录下的文件暂且不说,把目光集中在.git/HEAD和.git/refs/heads/master上/

显示一下.git/HEAD的内容.

引用的就是.git/HEAD和.git/refs/heads/master 看一下这个文件的内容.

显示的e5b70@##$$$是什么东西?用git cat-file命令查看

是一个commit对象,显示这个commit的对象提交的内容:

原来分支master指向的是一个提交ID,是最近的一次提交.这样的分支实现多么巧妙,:

既然可以从任何提交开始建立一条历史跟踪链,用一个文件执行这个链条的最新提交,那么这个文件就可以追溯整个提交历史了,这个

文件就是.git/refs/heads/master文件.

一个更真实的版本库结构图:

目录.git/refs 是保存引用的命名空间.其中.git/refs/heads 目录下的引用又称为分支.

对于分支,既可以使用正规的长格式的表示法,如refs/heads/master,也可以直接用master来表示.

一个提交中居然包含了三个SHA1哈希值表示的对象ID:

第一行commit @!@@@### 这个是本次提交的唯一标识.

第二行 tree @@##$$$$ 这个是本次提交所对应的目录树

第三行 parent &*(*^&^%%% 这个是本地提交的父提交(上一次提交)

研究Git对象ID的一个重量级武器就是git cat-file命令.见下图:

在引用对象ID的时候,没有必要把整个的40位ID写全.只要从头开始的几位不冲突即可.

下面再用git cat-file 命令查看一下这几个对象的内容.

commit对象e5b70b@##$#@@@@@

tree对象 65443c$%^&$$###

并且可以看到多了一个新类型的对象:blob对象,这个对象保存者各个文件对应的内容.

用$ git cat-file -p @#$#$ 命令显示了welcome.txt中的内容.

这些对象保存在了哪里?当然是Git库中的objects目录下了(ID的前2位作为目录名,后38位位文件名)

Git对象库中各个对象之间的关系见下图:

通过提交Commit对象之间的相互关联,可以很容易的识别出一条跟踪链.

HEAD和master的讲解: