Git原理与使用一
- 一.Git的初识与安装
- 1.什么是Git
- 2.如何安装Git
- 1.git命令与git help(Git下的"man手册")
- 2.centos下安装Git
- 3.ubantu下安装Git
- 二.Git的前置操作与前置知识
- 1.创建Git本地仓库
- 2.配置Git
- 3.理解Git的分区
- 1.工作区
- 2.暂存区
- 3.版本库
- 4.分区关系总结
- 三.添加文件
- 1.git add
- 2.git commit
- 3.git log查看历史提交记录
- 4.git log --pretty=oneline
- 四.初步认识.git目录
- 1.初步介绍
- 2.HEAD跟master分支
- 3.object和commit id
- 4.总结
- 五.git diff查看修改
- 六.版本回退
- 1.git reset
- 2.演示
- 1.--soft
- 2.--mixed
- 3.--hard
- 4.版本回退的实质
- 5.版本回退中的后悔药
- 七.撤销修改
- 1.未add
- 2.已经add,还未commit
- 3.已经commit了,但是还没有push
- 4.已经push了
- 八.删除文件
- 1.能否直接rm呢?
- 2.误删
- 3.的确要删除
一.Git的初识与安装
1.什么是Git
Git是一个版本控制器
在这里我们重点介绍Linux操作系统下的Git的使用
因为在未来的开发过程中Linux操作系统的使用更为频繁
而且Git最初就是在Linux操作系统下面开发的
2.如何安装Git
1.git命令与git help(Git下的"man手册")
首先我们可以使用git命令来查看我们有没有安装Git
git
如果结果中有:
command not found:说明我们还没有安装Git
如果结果是这样的
说明我们已经安装过Git了
在这里我们可以使用
git help Git下的具体命令/概念
来查看对应命令/概念的使用文档
跟man手册类似,按q键退出
2.centos下安装Git
安装git命令:
sudo yum install -y git
查看git安装的版本:
git --version
3.ubantu下安装Git
安装git命令:
sudo apt-get install -y git
查看git安装的版本:
git --version
二.Git的前置操作与前置知识
我们要想对文件进行版本控制
就必须先创建出一个仓库出来
仓库:进行版本控制的一个文件目录
1.创建Git本地仓库
我们目前在gitblog目录下面,我们想在这个目录下面创建一个git的本地仓库
使用命令:
git init
这个.git目录是Git用来跟踪管理仓库的,不要手动修改这个目录里面的文件,如果改乱了,那么就把Git仓库给破坏了
关于Git仓库里面有很多细节,大家感兴趣的话可以看一看
tree .git
这里面的一部分属性我们以后都会介绍的
我们在以后的操作当中为了方便理解
也经常会去这样看这个Git仓库
2.配置Git
当我们安装完Git之后首先要做的事情就是
设置用户名称和email地址
如何进行配置呢?
git config user.name "用户名称"
git config user.email "email地址"
还有一个选项:--global:
git config --global user.name "用户名称"
git config --global user.email "email地址"
这个--global的意思就是:如果加上这个--global
那么就表示这台机器上的所有的Git仓库都会使用这个配置.
如果你希望在不同仓库中使用不同的用户名或email地址
那么可以不加这个选项
查看配置:
git config -l
删除配置:
git config --unset user.name
git config --unset user.email
git config --global --unset user.name
git config --global --unset user.email
下面我在去配置一个用户名和email
这次我配置一个不带–global选项的
如何进行配置,如何查看配置,如何删除配置都给大家介绍完毕了
大家可以自行配置
3.理解Git的分区
1.工作区
工作区就是我们写代码或者文件的目录
也就是我们目前所处的
/home/wzs/wzsblog/gitblog
这个路径下(也就是包含.git的这个目录)
注意:
即使.git的确也是在gitblog这个目录下面
但是.git并不属于工作区!!!
平常我们在工作区中写代码(之所以被称为工作区也是这个原因)
写完之后如果想要将该文件交由Git来管理的话
就需要执行git add
命令将该文件添加到暂存区
2.暂存区
暂存区也可以被称为索引区
一般是存放在.git目录下的index文件中
之所以被称为暂存区是因为只有当执行git commit
命令之后,才能将暂存区中的文件添加到版本库中,才能让Git来管理这个文件!!
之所以被称为索引区,是因为暂存区其实存放的不是文件本身,而是文件的索引
这一点我们后续会详细介绍的,大家目前先知道这一点即可
当我们对于工作区修改或者新增的文件执行git add
命令之后
就会更新暂存区中的文件索引
3.版本库
版本库其实就是这个隐藏文件.git
这个版本库里面的所有文件都会被Git管理起来
每一个文件的修改,删除都会被Git跟踪记录到
以便于我们任何时刻都可以追踪历史或者"还原"(也就是版本回退,这一点我们以后会介绍的)
4.分区关系总结
关于git add和git commit命令我们下面就会进行介绍
三.添加文件
下面我们通过一个场景来介绍git add和git commit的使用方法
场景:
我们想要在工作区创建一个test.txt文件
然后通过git add和git commit来将这个文件交由Git管理
这是我创建的一个test.txt文件
这里为了方便,使用了echo与重定向新建test.txt并向其中写入
hello git
1.git add
下面我们就选择第一种来演示一下吧
其他的大家感兴趣的话也可以试试
这里介绍一个命令:
git status
这个命令可以查看当前git仓库的状态
他会提示我们接下来的操作
它提示我们接下来要进行git commit操作
2.git commit
下面我们来演示一下
3.git log查看历史提交记录
截至目前,我们成功将test.txt文件提交到本地仓库交由Git管理了
但是随着我们写的代码越来越多,要维护的文件也越来越多
我们难免会遗忘很多信息
因此git log就派上用场了
git log
可以用来查看历史提交记录
可是当我们提交的文件变多了呢?
比方说我现在又创建并提交了3个文件
然后git log
注意:git log命令是现实最近到最远的提交日志
这才仅仅是进行了2次提交,如果未来我们要进行几十次,几百次提交呢?
那git log就太不"善解人意"了吧…
4.git log --pretty=oneline
有没有一种简易的方法呢?
git log --pretty=oneline
此时只会显示commit id和我们写的提交信息
而且每一次的提交信息只占行
四.初步认识.git目录
目前我们向本地仓库添加完文件了
下面我们再去
tree .git
看一下.git的目录结构
来初步认识一下.git中到底有什么
1.初步介绍
2.HEAD跟master分支
下面我们就来看一下
这个HEAD存放的是什么?master存放的是什么?
3.object和commit id
下面我们来看一下这个object存放的是什么
我们就查看这个最近的一次提交吧
commit id是:76ba3c583103ad526fb5cd5281a539eac782dc49
git cat-file 76ba3c583103ad526fb5cd5281a539eac782dc49
在这里我们只介绍-p选项
其他选项大家感兴趣的话可以试一下
至此,大家只需要知道:
tree的commit id 保存的是当前提交和当前提交之前的所有提交的commit id
parent的commit id保存的是上一次提交时产生的commit id
其中,我们git log显示的都是parent的commit id
如果我们想要查看具体某个文件的修改
先查看git log显示的那一次提交的commit id的内容
然后tree
然后就能看到具体的文件的commit id了
然后就可以使用具体文件的commit id来查看对应文件的修改了
4.总结
后面在学习的过程中
大家最好能够将常见的git操作跟.git目录的结构内容的变化相对应起来
这样有助于我们理解git的细节流程
五.git diff查看修改
我们可以看出,上面那种查看修改的方法实在是有些麻烦
难道就没有什么更好的方法能让我们查看修改吗?
当然有啦
首先我们先对test.txt进行一次修改吧
我们使用追加重定向新增了两行内容
此时,本地仓库中的test.txt文件跟我们工作区的test.txt文件就不同了
我们也可以使用
git status
来查看在我们上一次提交之后有没有对文件进行再次修改
此时因为我们既没有add,更别提commit了
因此当前暂存区和版本库(本地仓库)中的内容是一样的
所以此时
git diff 和 git diff HEAD显示的结果是一样的
下面我们git add
让工作区和暂存区的内容一致
此时git diff就和git diff HEAD的结果不一致了
然后下面我在git commit
此时工作区的文件就跟暂存区和版本库中的文件没有任何差异了
六.版本回退
之前我们也提到过,Git 能够管理⽂件的历史版本,这也是版本控制器重要的能⼒
如果有⼀天你发现之前的代码出现了很⼤的问题,需要在某个特定的历史版本重新开始.
这个时候,就需要版本回退的功能了
1.git reset
关于具体的
–soft --mixed --hard这三个选项,大家可以看这个表格
下面我们修改test1.txt这个文件
并且进行add 和 commit操作来让暂存区和版本库的内容都更新为
test1
准备工作已经做好了
我们规定:
这三个选项的所有初始状态都是当前状态(初始版本都是当前版本)
都要回退到test1.txt的内容是test1.txt的那个版本
也就是这一个版本
2.演示
1.–soft
下面我们再使用git diff来看一下是否真的只有版本库被回退了
可见–soft的确是只会回退版本库
而不会回退暂存区和工作区
然后我们commit调整为我们规定好的初始状态
2.–mixed
下面我们用–mixed来回退
然后我们add commit调整为我们规定好的初始状态
3.–hard
下面我们用–hard来回退
4.版本回退的实质
5.版本回退中的后悔药
可是如果我不小心用–hard之后后悔了怎么办?
现实生活中很多时候是没有后悔药可吃的
但是git给了我们一次机会
我们可以使用
git reflog
这个命令是用来记录本地的每一次命令的
我们可以找到我们进行版本回退前的那个版本
然后我们就可以再次使用git reset回退到那个版本
就相当于吃了后悔药了
刚才演示完–hard之后,我后悔了
我要吃后悔药
下面给大家演示一下,顺便证明一下版本回退的实质
此时master里面存放的的确是我们之前规定好要回退到的那个版本
下面我们使用git reflog
可见Linux不仅仅是一种操作系统,它也是一种哲学,一种艺术啊
此时,回退成功
后悔药生效了
而且此时master分支当中存放的版本也改变了
这也证实了版本回退的实质
七.撤销修改
如果我们在我们的⼯作区写了很⻓时间代码,越写越写不下去,觉得⾃⼰写的实在是垃圾,想恢复到上⼀个版本
此时怎么办呢?
下面我们分为三种情况来介绍
我们这次对test2.txt进行操作
先修改test2.txt的内容
1.未add
直接执行
git checkout -- test2.txt
丢弃工作区的修改即可
成功撤销之前的修改
然后我们恢复成刚才的样子,并进行add为下面做准备
2.已经add,还未commit
此时我们先进行暂存区的版本回退
使用–mixed选项
git reset --mixed HEAD
通过版本回退将暂存区回退了之后,下面我们只需要回退工作区即可
git checkout -- test2.txt
回退成功
然后继续为下面做好准备
3.已经commit了,但是还没有push
下面会说明什么是push的
此时我们就要用
git reset --hard HEAD^
这里为什么是HEAD^呢
因为我们commit之后把版本库的HEAD指针更新了
所以要回退到上一次HEAD指向的版本
其实跟直接版本回退的情况是一样的
4.已经push了
注意:只有commit之后才可以push
八.删除文件
注意,在Git中不仅新建文件是修改操作
删除文件也是修改操作
下面我们要删除test2.txt
1.能否直接rm呢?
我们来演示一下:
2.误删
git checkout -- test2.txt
成功恢复
3.的确要删除
git rm test2.txt
git commit -m "提交信息"
成功删除
以上就是Git的原理与使用(一):Git的基本操作跟版本回退到的全部内容,希望能对大家有所帮助!