Git基本介绍(三大分区及核心内部构造)

1. Git三大工作区(工作区、暂存区和版本库)

  

  工作区(WORKING DIRECTORY): 直接编辑文件的地方,肉眼可见直接操作;

  暂存区(STAGIN AREA):数据(快照)暂时存放的地方;

  版本库(GIT DIRECTORT(RESPOSITORY)):存放已经提交的数据,push 的时候,就是把这个区的数据 push 到远程git仓库了。

  git add就是将工作区的修改缓存在暂存区,git commit就是将暂存区的数据快照提交到本地库

  这就是为什么 git commit 之前要先执行 git add 的原因,如果不先执行add,那么直接执行commit时不会把当前的修改内容提交到代码库中的。

 

2. Git 基本概念(实体、引用和索引)

实体:

  提交到 git 代码仓库中的所有文件,包括每个提交的说明信息,目录结构等都会转换成 git 实体

  所有实体均存在于.git/objects/目录中

  git中每一个实体以一个40字符长度的十六进制字符串来唯一标识

  git中包括4种类型的实体:

    1.blob-存储文件内容

    2.tree-存储目录结构和文件名

    3.commit-存储提交的作者、日期、说明等

    4.tag- 存储指向特定提交对象的引用

引用:

  Git 中,一个分支(branch)、远程分支(remote branch)或一个标签(tag)(也称为轻量标签)仅是指向一个实体的一个指针,这里的实体通常是一个commit实体。这些引用以文本文件的形式存储在目录 .git/refs/ 中符号引用(Symbolic References)Git 有一种特殊的引用,称为符号引用。它并不直接指向一个实体,而是指向另一个引用。举例说,.git/HEAD就是一个符号引用。它指向你正在工作的当前分支。

索引:  

  索引是一个暂存区,以二进制文件的形式存储为文件 .git/index 中当git add 一个文件,git 将该文件的信息添加到索引中当git commit时,git 仅提交索引文件中列出的文件到 git 本地仓库

 

实体、引用和索引之间的关系:

 

测试说明:

  1. 新建一个readme,txt并提交到本地库

git add readme.txt
git commit -m 'first commit'

   2. git log查看commit实体,可以看出对于的SHA1值为999976c43b0e684f1bf7af4bed1acd11b3afa636

  

  3. git cat-file目录查看该commit实体的内容, 可以看出该commit实体包含了提交的作者及邮箱等全局信息,除此之外还包括了一个tree实体, 该实体的SHA1值为bb527569763dcd71a5dcd4b9a4ba692f1ebb56c0

  

  4. 使用git ls-tree查看该tree实体, 发现tree实体中包含了一个blob实体, 该实体的的SHA1值为0cce6dff89d87d991136ad27e18c928eb65f5bb3

  

   5. 使用git cat-file -p XXX查看blob实体内容, 可以发现blob实体存储的就是readme.txt文件内容

  

  6. 此时我们查看.git/refs/heads/master文件内容,可以发现其刚好为commit实体的SHA1值,也就说明 master 为一个 引用 ,并且指向最后一个 commit 实体

  

  7. 在刚刚介绍中,我们知道了tag实体存储了指向指定commit实体的引用,下面来创建一个标签"version1.1", 通过git rev-parse tagname来查看tag实体的SHA1值,再通过git cat-file -p XXXX可以发现该tag内部即为commit实体,且该commit实体为最后一次提交的实体

  

  8. 至此我们生成了四个实体,分别为

    999976c43b0e684f1bf7af4bed1acd11b3afa636  ----commit实体

    bb527569763dcd71a5dcd4b9a4ba692f1ebb56c0   ---tree实体

    0cce6dff89d87d991136ad27e18c928eb65f5bb3   ---blob实体 

    50e5866a324c6e2afaf6374c39b4b93d394b504a  --tag实体

  8. 查看各实体、引用、索引的储存位置

    实体(.git/objects/):以SHA1头两位作为文件名

    

    引用(.git/refs): heads下存储历史commit实体, tags下存储每一个标签

    

    索引(.git/index):

     

    通过git ls-files --stage查看.git/index文件内容,可以发现并非存储着最新commit实体的SHA1值而是其commit实体关联的blob实体SHA1值

    

    再次测试.git/index中文件内容, 我们新建一个文件index并提交到本地库

    

    

 

 3. Git SHA1

  git 为每一个实体生成一个160位的散列值,通常使用40个字符长度的16进制字符串表示

散列碰撞:

  几乎不会出现散列碰撞情况(相同SHA1,出现冲突)

  通常情况下你不需要担心该散列值会产生碰撞,对于 160 位数,你有 2160 或者大约 1048 种可能的 SHA1 散列值。这个数有多么巨大,你可以简单感受下,即使你雇一万亿人来每秒产生一万亿个新的唯一 blob 对象,持续一万亿年,你也只有 1043 个 blob 对象,所以你基本不用担心该散列值会产生碰撞,而且只有当不同的内容产生了相同的 SHA1 散列值才能称为碰撞。

git 基于内容的 SHA1:

  对应相同的内容得到的永远是相同的 SHA1

  之前已经提到过 git 会为每个实体生成一个唯一的 SHA1 值来标识该实体,并且 git 会将生成的实体以二进制文件的形式保存在 .git/objets 目录下,但是 git 在生成 SHA1 时并不是简单地基于文件名、文件路径、创建者及创建时间组合起来,相反 git 是基于内容来生成 SHA1,试想一下,如果我们项目中有一个 a.txt 文件,分别存放在 dir1,dir2 目录下,这时候 git 并不会为 dir1/a.txt 和 dir2/a.txt 文件创建两个 blob 实体,因为 a.txt 虽然在两个目录下,但是他们的内容是完全一样的,所以 git 在生成实体时,通过散列算法,git 会发现这两个文件得出的 SHA1 值是完全一样的,所以 git 只会保存一个 blob 实体。这样可以避免当我们再重命名文件,或者移动文件所在目录时,生成重复的 blob 实体,这也得益于 git 基于内容的散列算法可以很好地发现这两个文件其实是同一个文件。

测试:

  

 

4. git 特殊符号引用介绍

git 自动维护了几个用于特定目的的特殊符号引用。这些引用可以在使用提交的任何地方使用。

  • HEAD 始终指向当前分支最终提交。当切换分支时 HEAD 会更新为指向新分支的最新提交。
  • ORIG_HEAD 某些操作,例如 merage / reset 会把 merge 之前的 HEAD 保存到 ORIG_HEAD 中,以便在 merge 之后可以使用 ORIG_HEAD 来回滚到合并之前的状态(在分支合并的时候,产生了冲突,如果已经修改了冲突,并产生了新的提交,但是冲突解决的有问题,想要还原之前的状态重新合并,这时可以使用 git reset --hard ORIG_HEAD 来还原到合并之前的状态)。
  • FETCH_HEAD 当使用命令 git fetch 抓取远程仓库更新时,FETCH_HEAD 保存着最近抓取的分支的 HEAD。
  • MERGE_HEAD 当一个合并正在进行时,其他分支的头暂时记录在 MERGE_HEAD 中,换言之, MERGE_HEAD 是正在合并进 HEAD 的提交。

 

posted @ 2019-08-25 17:55  风来与你安  阅读(1157)  评论(0编辑  收藏