0


Git的原理与使用(一):Git的基本操作(包含:版本回退)

Git原理与使用一

一.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了
在这里我们可以使用

githelp Git下的具体命令/概念

来查看对应命令/概念的使用文档
在这里插入图片描述
跟man手册类似,按q键退出

2.centos下安装Git

安装git命令:
sudo yum install-ygit
查看git安装的版本:
git--version

在这里插入图片描述
在这里插入图片描述

3.ubantu下安装Git

安装git命令:
sudoapt-getinstall-ygit
查看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.的确要删除

gitrm test2.txt
git commit -m"提交信息"

在这里插入图片描述
在这里插入图片描述
成功删除

以上就是Git的原理与使用(一):Git的基本操作跟版本回退到的全部内容,希望能对大家有所帮助!

标签: git linux 版本回退

本文转载自: https://blog.csdn.net/Wzs040810/article/details/134567705
版权归原作者 program-learner 所有, 如有侵权,请联系我们删除。

“Git的原理与使用(一):Git的基本操作(包含:版本回退)”的评论:

还没有评论