git本地仓库结构

本地仓库结构

git项目有3个主要的部分组成:工作区(working directory / working tree),暂存区(staging area),版本库(git directory / repository)
git directory / repository:git版本库,其实就是git用于存储自己的元数据,以及文档数据库的地方,默认就是在项目的.git隐藏目录中
working directory / working tree:工作区,保存的是一个项目当前的一个版本对应的所有文件,这些文件是从git版本库中的压缩后的数据库中提取出来,然后放到我们的磁盘上去。
staging area:暂存区,就是一个文件,包含在git版本库中,主要是保存了下一次要提交到的那些文件信息。在git中,对暂存区有另外一个名称,叫做index,也就是索引。
上面三个区域的协作关系大致如下:
(1)首先会在工作区修改某个版本的文件 (2)将某些修改后的文件放入git暂存区中,准备下一次提交到git版本库中去 (3)执行一个提交操作,将暂存区中的文件保作为一个快照保存到git版本库中去
如果一个文件,已经有一个版本被保存到了版本库,那么就是committed状态;如果这个文件被修改了,同时被加入了暂存区,那么就是staged状态;如果这个文件修改了,还没有加入暂存区,那么就是modified状态。 工作区,working directory
所谓的工作区,指的就是当前你的git管理的项目,在本地的那个目录,也就是你能直接看到,编辑的那个目录,这就是工作区。
notion image
未提交到暂存区文件为红色. 提交到暂存区为绿色,
 

git的重要机制

Git有很多特有的机制,都是跟普通的版本控制系统不一样的
(1)快照机制
普通的版本控制系统,比如说CVS,SVN等,是通过一开始提交一个原始文件,然后后面每次对文件进行修改之后再次提交,都维护这次提交对应的一个差异,通过维护每个版本的差异,就可以通过应用差异,或者回退差异,来前进或者后退文件的版本。
Git用的不是这种维护每次提交的差异,而是用的快照。每次提交文件,都是保存一份这个文件当前这个状态的一个完整快照,同时对这次提交维护一个指针,指向这个文件快照。
(2)本地化操作
大多数的git版本控制操作,只要在本地执行即可,所有的版本文件都在本地,因此操作是非常快速的。相比较于那些依赖网络的集中式版本控制系统来说,他们的大多数操作要依赖网络,速度是很慢的。
比如说通过git查看提交历史,比较历史文件的差异,都可以在本地完成,不需要通过服务器做任何事情。
如果我们在飞机或者或者上,没有网;或者在家里,没有vpn。都没有问题,随便做开发、写代码,提交代码,在本地就可以了,等有网络的时候,再把提交的版本推送到远程服务器上去。但是SVN之类的,就不可以提交了,因为没有网,没法连接到服务器。
(3)完整性保证
git在存储任何文件之前,都会对其执行一个校验和,然后用校验和指向那个文件。这是git内核保证的,这样我们是不可以手工修改git版本库中的任何文件的,因为修改了文件之后,会导致计算出来的校验和与之前保存的校验和不匹配,文件会破损。
git用的是SHA-1 hash算法来计算校验和,这是一个40位的字符串,基于文件的内容计算出来的,看起来大概是这样的:
24b9da6552252987aa493b52f8696cd6d3b00373
如果手动破坏.git中存储的文件的内容,git会不承认,因为内容变化之后,会导致内容计算出来的SHA-1 40位的hash值变化,跟之前存储的hash值不同,就认为文件破损
(4)仅仅添加数据
git通常来说,仅仅会在自己的数据库中添加数据,因此提交文件到git之后,很少会丢失,而且如果我们定期提交文件到远程服务器,就更少丢失。

git status查看代码文件的状态

代码文件分成两种,一种是tracked,一种是untracked。tracked文件就是已经提交到git版本库中的文件,后面可以处于modified或者staged状态;untracked文件,就是从来没有提交到git版本库的代码文件(也从来没有放入暂存区)。
在oa-auth的server包下,可以新建一个TestServiceImpl.java,然后执行git status命令,看一下当前的状态,红色文件还在工作区没有提交到暂存区
notion image
此时git status会告诉你,有文件没有被提交到git仓库中或者是暂存区中过,就是untracked,就是从来没有被git追踪过它的版本,甚至第一个版本都没有被git追踪。
接下来执行命令:
git add --all .,也可以给大家开始来解释一下这些命令的含义,git add .,就是将当前新增或者是修改过的文件,加入暂存区,但是加了--all之后,如果有文件被删除,也会将文件被删除的状态加入暂存区中
一般工作中,都是用git add --all .
但是也可以直接git add 某个文件,把指定的文件加入到暂存区中
notion image
从暂存区提交到仓库
notion image
总结一下 (1)新文件刚创建:untracked,此时仅仅停留在工作区中 (2)git add 新文件:new file,此时已经被追踪了,放入了暂存区中 (3)git commit 新文件:committed,已经被追踪了,放入了git仓库中 (4)修改那个文件:modified,changes not staged to be committed,没有加入暂存区,被修改的内容仅仅停留在工作区中 (5)git add 修改文件:modified,changes to be committed,修改的文件版本被已经加入暂存区 (6)git commit 修改文件:committed,修改后的新版本提交到了git仓库中
一般自己创建的版本库,刚开始文件都是untracked,然后git add和git commit命令执行之后,就被提交了第一个版本到git版本库,此时就全部都是tracked了。如果是从远程版本库克隆下来的,那么刚开始就是tracked。
接着对tracked的文件修改之后,就是modified;然后对modified文件再执行git add命令之后,就是staged,进入了暂存区;接着执行git commit命令之后,就将暂存区中的文件都提交到了版本库中,此时就是unmodified,and tracked。
6种状态映射到3种状态的补充说明
git管理的文件有三种状态:提交状态(committed),修改状态(modified),暂存状态(staged)。
提交状态:我们的文件已经安全的保存在git的本地数据库中了。 修改状态:我们修改了文件,但是还没有提交到git的数据库中去。 暂存状态:将修改后的文件标记为即将通过下一次提交,保存到git数据库中去。
(1)新文件刚创建:untracked,此时仅仅停留在工作区中 (2)git add 新文件:new file,此时已经被追踪了,放入了暂存区中 => staged (3)git commit 新文件:committed,已经被追踪了,放入了git仓库中 => committed (4)修改那个文件:modified,changes not staged to be committed,没有加入暂存区,被修改的内容仅仅停留在工作区中 => modified (5)git add 修改文件:modified,changes to be committed,修改的文件版本被已经加入暂存区 => staged (6)git commit 修改文件:committed,修改后的新版本提交到了git仓库中 => committed

git log

在我们提交了很多次之后,可以查看提交历史,使用git log命令即可,可以看到每次commit的信息,包括了commit的SHA-1、作者、日期、提交说明。
包含了一个commit的SHA-1 hash值,40位的字符;作者,从之前安装好git之后做的设置来的;date;提交备注,inital commit,git commit -m ''
notion image

head 指针

(HEAD -> master)是什么意思?
版本控制系统中,都有一个概念,叫做分支,就是同样的一份儿代码,可以拉取多个分支,每个分支的代码刚开始都是一样的,然后不同的人可以基于不同的分支去开发,然后开发完之后,再将多个分支的代码合并在一起
分支,就是一份代码拷贝,基于这份独立的代码拷贝,去写自己的代码
最后将多个分支合并在一起,就是将不同的人写的代码合并到一起
git里面,每次git init之后,默认初始就创建一个分支,叫做master分支
我们每次写代码,然后git commit提交,都会形成一次新的commit,然后默认就是在master分支对应的代码拷贝上,进行代码修改和提交的
每次提交之后,master分支就会对应着最新的一次提交
HEAD,指针,指向了我们当前所处的分支,因为当前我们默认就处于master分支上,所以HEAD指针就是指向master的
 

日志其他子命令

git log --patch -2,--patch可以显示每次提交之间的diff,同时-n可以指定显示最近几个commit。这个是很有用的,可以看最近两次commit之间的代码差异,进行code review是比较方便的。
用git log --stat,可以显示每次commit的统计信息,包括修改了几个文件,有多少行插入,多少行删除。
用git log --pretty=oneline,可以每个commit显示一行,就是一个commit SHA-1和一个提交说明。用git log --pretty=format:"%h - %an, %ar : %s",可以显示短hash、作者、多长时间以前、提交说明。
用git log --oneline --abbrev-commit --graph,这是最有用的,可以看到整个commit树结构,包括如何合并的,就显示每个commit的SHA-1和提交说明,同时SHA-1显示短值。
  • -oneline:显示一行,不要显示多行那么多东西,一行里,就显示commit的标识符,SHA-1 hash值,40位的;提交备注;显示分支和HEAD指向哪个commit
  • -abbrev-commit:commit的标识符,每一次commit,都有一个唯一的标识符,就是一个SHA-1 hash值,40位,显示一个短值,默认显示前7位,就是说前7位就可以唯一定位这个commit了,不需要完整的40位
  • -graph:显示图形化的commit历史,这个大家后面学习到分支那里就知道了,如果有分支的话,commit历史会形成一棵树的形状,这个时候用--graph可以看清楚这颗commit树长什么样子,很有的
告诉大家,通过git log命令,就可以看到你多次往git仓库中提交不同代码版本的整个历史
 

图解git日志原理

就是你每次git add之后,git commit之后,会在git仓库里存储什么东西,存储的那些东西跟分支还有HEAD之间的关系是什么???
用一张图画清楚,工作区、版本库、暂存区、master分支以及HEAD指针的关系
工作区和版本库是两个分离的区域
在工作区修改代码之后,执行git add命令,会将代码放入版本库中的暂存区;接着执行git commit命令之后,会将暂存区中的代码提交到版本库中的master分支上,而HEAD指针就指向master分支的最新一次提交。
所以现在我们就很清楚了,git add,其实就是可以多次修改代码,多次git add,然后将每次修改的代码,都放入暂存区中
;而git commit,就是一次性将暂存区中的代码,全部提交到master分支上,master分支会出现一个最新的commit,也就是一个最新的代码版本;
而HEAD作为一个指针,永远指向master分支的最新一次commit的代码版本。
notion image

git reset

git reset --hard HEAD^,就可以回退到上一个版本
HEAD^,代表了什么?
HEAD -> master -> commit(add methods for classes)
HEAD^,代表的是commit(add methods for classes)的上一个commit(add two files)
git reset --hard HEAD^,就是将仓库、暂存区、工作区,全部恢复到上一个commit(add two files)对应的状态
git reset --hard HEAD~5,退回到HEAD之前的倒数第5个commit的状态
git reset --hard d324644,指定一个commit的hash值,回退到很老的版本
git reset这个命令,可以任意穿梭到历史的任何一个版本上去
 
 
notion image
 
  • 软, master 分支reset到modify这个提交对象, 本次新增/修改的文件保留在暂存区
  • 混合 , master 分支reset到modify这个提交对象, 本次新增/修改的文件保留在工作区,需要自己add到暂存区
  • 硬, , master 分支reset到modify这个提交对象, 本次新增/修改的文件丢失
  • 保留 master 分支reset到modify这个提交对象, 本次新增/修改的文件丢失

git reflog

如果我要回来呢?重新回到之前add methods for classes那个commit对应的版本
notion image
找回之前的分支
notion image
实现了我们第一讲所说的,版本管理的困难,被git轻易的解决了
(1)记录下来了每一个版本 (2)可以让我们通过简单的命令,在任何一个版本中任意穿梭,实现了版本控制功能
git最核心的原理
(1)三个区域:工作区、暂存区、仓库 (2)提交历史:在仓库中,blob->tree->commit->master-HEAD,这套东西形成了git的数据结构