git基本观点与原理

-----------------------------------------------------------------------------------------------------------------------------------------------

一、git的安装与简朴设置

1安装

apt install -y git-core

2设置git名称与邮箱

git config --global user.name "chenux"

git config --global user.email "json_chenux@163.com"

git config --global --list   

mkdir 目录 && cd 目录

git init git_repo   #git_repo就是堆栈,其目录下有个.git

3git设置优先级

git config --system:使对应设置针对系统内所有的用户有用

git config --global:“使对应设置针”对当前系统用户的所有堆栈生效

git config --local:使对应设置只针对当前堆栈有用

local选项设置的优先级最高。

4、堆栈中有文件后,保留库状态

在堆栈中执行下令git add . && git commit -m "status01"

给堆栈里加了些文件

5、gitk,图形化git管理工具,apt install -y gitk

 

6、此图状态为在4中已经执行过的状态,此时输入指令更改文件内容

echo aa11a1 >1.txt \

echo b2b2b2 >> 2.txt \

touch project/pro-2.txt

执行后保留状态git add. && git commit -m status02,此时再启动gitk

 

再次稍作修改后保留一次状态

 

二、git工具

1、三种差别类型的git工具:

1blob:一个blob就是由一个文件转换而来,blob中只会存储文件的数据,而不会存储文件的元数据

2tree:一个tree就是有一个目录转换而来,tree只会存储一层目录信息,它只存储它的直接文件和直接子目录的信息,但子目录中的内容它不会保留

3commit:一个commit就是我们的git commit提交,它指向了一个tree,这个tree保留了某一时刻项目根目录中的直接文件和直接目录信息

总而言之,commit指向了treetree又指向了自己根下直接文件的blob或者子目录的tree,子目录的tree工具指向了子目录的文件blob和子子目录的tree,以此类推

2、每个git工具都有一个唯一的哈希码(SHA1算法),它是一个40位的16进制数

3、在初始提交后再举行二次提交,若存在

文件f1没有修改,在此历程后,它的blob哈希没有改变;

文件f2修改内容,在此历程后文件为f22,它的blob哈希发生改变;

存放f1f2的目录ALPHA,在此历程中它的tree哈希发生改变,但指向文件f1blob仍为a以前的blob

 

三、git历程

1、目录结构

 

可以看到,堆栈内部除了自己建的文件,另有一个.git目录,该隐藏目录在git init时刻就已经天生了。

.git目录:可以称之为版本库

2、在之前提交的下令中,输入的是

1git add -A:选择将哪些转变的内容加入到下一次提交中,这些转变内容会被索引或者暂存起来,此时天生文件的blob

2git commit -m STATUSNAME:建立commit提交工具,执行下令后git会凭据索引/暂存中的结构,建立出对应的tree工具,之后git会建立一个commit工具,将新建立的commit工具指向新建立的tree

3)这个新的提交发生后,记录了一个状态,该提交也会指向前一次的提交,每个提交都市指向自己的父提交

 

(4)图片所示,当修改3.txt后,由于它是位于上一次状态中,修改它后会变红,等git add 3.txt后它的状态变为绿色,解释已加入暂存区,做好随时被提交的准备。4.txt由于没有提交,一直是红色,解释还在事情区

 

四、git使用

1git log

显示所有的git提交,git log --onelinegit log的简朴模式

 

git cat-file -t 哈希值 查看工具的类型

git cat-file -p 哈希值 查看工具的内容

git rev-parse 13614 通过简短的哈希值获取到整个哈希值

2、有如下操作:

git init git_test

cd git_test

echo f1>f1                                                                                         echo f2>f2

git add .

git commit -m "test01"

echo -e "haha \nheihei" >> f1

git add .

git commit -m "test02"

我们可以得知f1『发生了』转变,若是我们此时悔恨了对f1的操作,执行下令

git log --oneline,先找出对应提交的哈希值,之后git reset --hard 82a23e7

 

不难发现,虽说文件恢复到test01的状态了,然则适才test02没了,现在若是想再次回到test02,该若何操作?

1git reflog,输入后可以查看之前的test02哈希码,查询到后 git reset --hard 哈希码便可回复

 

2)验证下,恢复乐成

 

五、git分支

1、在现实环境中,文件的修改是纵容交织的,‘以是存在一个’问题:文件回退时,是否会影响其它文件?这里就会引入一个观点:分支

git status,显示位于主分支master

 

建立新分支时,默认以当前所在分支为基础建立,建立后分支的最新提交与master一样

1)建立分支,使用下令git branch分支名

 

建立后事情区仍处在master分支上,未切换到新建的slave分支。分支的建立,并不是说明slave复制了master的分支,而是git只是建立了slave分支指针,指向了master分支对应的最新提交。

逻辑图如下:

2)查看分支情形

git branchgit branch -vgit branch -vv

(3)分支切换

git checkout 分支名

切换后事情区也随之切换,之后的git addgit commit下令影响切换后的分支

 

现有操作

 

切换到我的分支slave后,输入指令后再提交,此时逻辑图就变为了

master上有5个提交,而slave上有6个提交。这时在切回master分支,看下f2文件,内容并没有改变。

 

 同理,若此时在master分支修改任何文件,切换到slave分支是看不到master修改的文件,因此在项目时可以行使分支,卖力某个项目a模块开发的修改文件在分支1,卖力b模块开发的修改文件在分支2,后期项目合并时分支合并即可。详细的合并分支在后面。

六、HEAD

1HEAD指向分支

我们从之前图中可以看到,通常情形下,当处于哪个分支,HEAD就指向了哪个分支,以是git是通过HEAD找到自己所处的事情区,在git堆栈下的.git里,可以查看HEAD的文件内容,其内部显示就是现在指向的分支。

 

(2)HEAD指向提交

特殊情形下,HEAD可以指向某个提交,这种情形称作头星散,detached HEAD

如上图所示,HEAD没有指向任何一个分支,而是指向了commit2这个提交。怎样才能泛起这种效果呢?git checkout COMMIT_HASH,如图示

 

此时输入指令,git log --oneline --all --graph

 

再看下此时的git status

 

星散头使用场景:

对该提交点的文件可以随便看看,或者做一些实验性的修改,而且可以将这些修改做成 提交,提交后会组成匿名分支,若是最后实验效果不满足可以抛弃之前实验行的提交, 若是实验效果满足,就可以建立一个新的分支,来永远保留这些提交。

示例:首先星散头已经指向了51fe144,此时输入了以下指令:

sed -i "s/\:/\-/g" 1.txt

git add 1.txt  && git commit -m "head_modify_1.txt"

echo headtest2 > 1.txt

git add 1.txt  && git commit -m "head_modify_1.txt-02"

修改了两次,提交了两次,我们此时通过图形工具看一下

gitk --all

 

注:这里星散头选的提交恰好选到master分支的最新提交了,这能说明星散头是从master“分支分出”来的

修改完成后,随便切换一个分支,会泛起提醒,好比我在git checkout test后,有图

 

若是修改项目后实验效果满足,就可以使用提醒的下令

git branch 分支名 哈希值

输入git branch headfile 65a96e4

 

若是不想保留实验性修改,切换分支后不用去管提醒即可