git基本概念与原理git
-----------------------------------------------------------------------------------------------------------------------------------------------算法
1、git的安装与简单配置json
1、安装app
apt install -y git-coreide
2、配置git名称与邮箱工具
git config --global user.name "chenux"spa
git config --global user.email "json_chenux@163.com"3d
git config --global --list 指针
mkdir 目录 && cd 目录对象
git init git_repo #git_repo就是仓库,其目录下有个.git
3、git设置优先级
git config --system:使对应配置针对系统内全部的用户有效
git config --global:使对应配置针对当前系统用户的全部仓库生效
git config --local:使对应配置只针对当前仓库有效
local选项设置的优先级最高。
四、仓库中有文件后,保存库状态
在仓库中执行命令git add . && git commit -m "status01"
给仓库里加了些文件
五、gitk,图形化git管理工具,apt install -y gitk
六、此图状态为在4中已经执行过的状态,此时输入指令更改文件内容
echo “aa11a1” >1.txt \
echo “b2b2b2” >> 2.txt \
touch project/pro-2.txt
执行后保存状态git add. && git commit -m “status02”,此时再启动gitk
再次稍做修改后保存一次状态
2、git对象
一、三种不一样类型的git对象:
(1)blob:一个blob就是由一个文件转换而来,blob中只会存储文件的数据,而不会存储文件的元数据
(2)tree:一个tree就是有一个目录转换而来,tree只会存储一层目录信息,它只存储它的直接文件和直接子目录的信息,但子目录中的内容它不会保存
(3)commit:一个commit就是咱们的git commit提交,它指向了一个tree,这个tree保存了某一时刻项目根目录中的直接文件和直接目录信息
总而言之,commit指向了tree,tree又指向了本身根下直接文件的blob或者子目录的tree,子目录的tree对象指向了子目录的文件blob和子子目录的tree,以此类推
二、每一个git对象都有一个惟一的哈希码(SHA1算法),它是一个40位的16进制数
三、在初始提交后再进行二次提交,若存在
文件f1没有修改,在此过程后,它的blob哈希没有改变;
文件f2修改内容,在此过程后文件为f22,它的blob哈希发生改变;
存放f1和f2的目录ALPHA,在此过程当中它的tree哈希发生改变,但指向文件f1的blob仍为a之前的blob
3、git过程
1、目录结构
能够看到,仓库内部除了本身建的文件,还有一个.git目录,该隐藏目录在git init时候就已经生成了。
.git目录:能够称之为版本库
2、在以前提交的命令中,输入的是
(1)git add -A:选择将哪些变化的内容加入到下一次提交中,这些变化内容会被索引或者暂存起来,此时生成文件的blob
(2)git commit -m “STATUSNAME”:建立commit提交对象,执行命令后git会根据索引/暂存中的结构,建立出对应的tree对象,以后git会建立一个commit对象,将新建立的commit对象指向新建立的tree
(3)这个新的提交产生后,记录了一个状态,该提交也会指向前一次的提交,每一个提交都会指向本身的父提交
(4)图片所示,当修改3.txt后,因为它是位于上一次状态中,修改它后会变红,等git add 3.txt后它的状态变为绿色,代表已加入暂存区,作好随时被提交的准备。4.txt因为没有提交,一直是红色,代表还在工做区
4、git使用
1、git log
显示全部的git提交,git log --oneline,git 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,该如何操做?
(1)git reflog,输入后能够查看以前的test02哈希码,查询到后 git reset --hard 哈希码即可回复
(2)验证下,恢复成功
5、git分支
1、在实际环境中,文件的修改是纵容交错的,因此存在一个问题:文件回退时,是否会影响其它文件?这里就会引入一个概念:分支
git status,显示位于主分支master
建立新分支时,默认以当前所在分支为基础建立,建立后分支的最新提交与master同样
(1)建立分支,使用命令git branch分支名
建立后工做区仍处在master分支上,未切换到新建的slave分支。分支的建立,并非说明slave复制了master的分支,而是git只是建立了slave分支指针,指向了master分支对应的最新提交。
逻辑图以下:
(2)查看分支状况
git branch、git branch -v、git branch -vv
(3)分支切换
git checkout 分支名
切换后工做区也随之切换,以后的git add与git commit命令影响切换后的分支
现有操做
切换到个人分支slave后,输入指令后再提交,此时逻辑图就变为了
master上有5个提交,而slave上有6个提交。这时在切回master分支,看下f2文件,内容并无改变。
同理,若此时在master分支修改任何文件,切换到slave分支是看不到master修改的文件,所以在项目时能够利用分支,负责某个项目a模块开发的修改文件在分支1,负责b模块开发的修改文件在分支2,后期项目合并时分支合并便可。具体的合并分支在后面。
6、HEAD
(1)HEAD指向分支
咱们从以前图中能够看到,一般状况下,当处于哪一个分支,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后
若是不想保存实验性修改,切换分支后不用去管提示便可