【Git版本控制器--1】Git的基本操作--本地仓库

目录

初识git 

本地仓库

认识工作区、暂存区、版本库

add操作与commit操作 

master文件与commit id

修改文件

版本回退 

撤销修改 

删除文件

---

初识git 

Git 是一个分布式版本控制系统，主要用于跟踪文件的更改，特别是在软件开发中。

---

为什么要版本控制？

需求：假设你的导师让你为一件产品写出一份文档。

当你写完以后，你拿给你的导师，你的导师并不满意，让你拿回去进行修改。此时你不进行版本控制，直接在原文档上进行修改，最终你改完以后又拿给你的导师，你的导师还是不满意。以此往复，你对原文档进行了10多次的修改，而此时你的导师又改主意了，让你拿出第一次修改后的文档，你该怎么办呢？

若是不进行版本控制，那么上述问题是无解的，因为你是直接对原文档进行的修改！

所谓的版本控制，就是让你有方式对自己修改的每一份代码都有备份！版本控制器的核心功能就是对这些备份进行管理。

版本控制器的本质就是记录每次的修改以及版本迭代的一个管理系统

git是目前最主流的版本控制器！git可以控制电脑上所有格式的文档。对于开发人员来说，git最主要的作用是可以用来管理源代码文件

• 对于文本文件来说，文件每一次上传到git，git都会记录你本次修改的内容，如：第二行新增了xxx
• 对于二进制文件来说，git并不会记录它修改的内容，只会记录文件大小的变化 

---

本地仓库

为什么要有本地仓库？ 

git是用于管理我们的文件的一个版本控制器，如果文件被分散在电脑的各个角落，git是无法进行管理的，所以git管理文件要求我们的文件必须是放在git仓库中的 

---

如何创建本地仓库

第一步：需要创建一个目录

第二步 ：在创建好的目录中使用如下指令

git init

输入完上述指令以后，会发现我们的目录下多了一个.git文件

这个文件是.git文件是git提供用于追踪并管理我们仓库的文件，一般来说不要手动修改.git中的内容

---

如何配置本地仓库？

配置本地仓库时，最主要配置的两个信息：

• name
• email

若不配置上述两个信息，git会报错

配置用户名称：

git config user.name "[用户名称]"

例如：

[yyf@VM-24-5-centos gitcode]$ git config user.name "yyf"

配置email邮箱地址：

git config user.email "[邮箱地址]"

 例如：

[yyf@VM-24-5-centos gitcode]$ git config user.email "[e-mail]"

 查看配置信息：

git config -l

 删除配置信息：

git config --unset [键值]

键值：user.name、user.email都是键值，查看配置信息时"="左边的都是键值

例如：

 一个主机当中，可以存在很多个本地仓库。并且我们可以一次设置所有本地仓库的配置信息

设置全局配置信息：

git config --global [配置键值] "[配置值]"

例如：

git config --global user.email "[e-mail]"

删除全局配置信息：

git config --global --unset [配置键值]

---

认识工作区、暂存区、版本库

 

如图，在包含.git文件的gitcode目录下我创建了一个ReadMe文件

但实际上这个文件并不能被git管理。这是因为gitcode文件并不是真实的git仓库。

真正的git仓库是.git文件

.git文件又被称为版本库/仓库！

虽然.git是仓库，但不能直接手动修改.git中的内容，这是不被允许的！

由于.git不能直接被修改，所以一般我们把要被管理的文件放在包含.git文件的目录下(图上gitcode)。而这个目录我们又称之为工作区！

注意：.git文件虽然是在工作区目录下，但.git文件不属于工作区

---

如何把工作区文件放到版本库中，使git能管理该文件？ 

• stage我们称之为暂存区/索引
• 图中其他概念，后面会阐述
• 如图所示，把工作区的所有修改内容添加到版本库中，是通过add操作实现的
• 修改内容：在工作区中创建文件、修改工作区的文件、在工作区的删除操作
• 注意：add操作是把工作区的内容放入到版本库的暂存区当中
• 把暂存区的内容放入到master中，是通过commit操作实现的！
• 当工作区的修改内容被commit到master以后，才真正意味着该内容被添加进了版本库中！

---

git的版本控制如何体现？ 

版本库中除了暂存区与master以外还会存在一个objects，即对象区 

 

而我们每次在工作区中add一个修改内容时，都会新增一个修改内容的git对象，该对象会被维护到objects中 

所以我们每次修改工作区的内容并生成一个新的git对象被维护到objects对象区中时，就相当于我们维护了一个版本！

暂存区和对象区之间的关系：

• objects对象区是实际存储修改内容对象的地方！
• stage暂存区是存储对象区的索引，所以一般来说stage都是较为轻量级的

commit操作做了什么？

• commit操作实际上就是把暂存区中的索引树，放入到master区
• 所以master区中存储的也是对象在对象区的索引，master区也是较为轻量级的 

 HEAD是一个指针，它指向了master区，我们只要拿到HEAD指针就能拿到master的那棵索引数

注意：有了HEAD指针就能找到master指针，所以版本库中并没有master区 

---

add操作与commit操作 

add/commit...操作对应的Linux命令 

add操作：git add [file1] [file2] ...

commit操作：git commit -m "message"  （message：本次提交的描述信息！）

如下：

我们在commit时，可以看到git的管理信息，即一个文件被改变，增加了1行 

获取工作区的所有的提交记录：

git log

• commit：即commit id，每一次提交时生成git对象的commit id都不同，它是通过某种哈希算法得到的！
• Author：表示提交的人是谁，我们之前配置的name和email都会显示在这
• Date：提交日期 

若上述的获取提交记录的方法，你觉得内容太多不好筛选，那么可以带上如下选项：

git log --pretty=oneline

 

 带上选项以后，只打印commit id和描述信息！

---

master文件与commit id

之前说过HEAD指针是指向master的，所以HEAD中保存了master的地址

我们会发现master文件中存储的实际上就是最近一次提交的commit id

之前说过commit id可以标识git对象，若我们拿着这个commit id那么就能到objects对象区中找到该对象！

找之前我们得先把commit id分为两个部分，最开始得两位数表示得是文件夹的名称，而其他位数表示的是文件的名称

---

如何查看git对象的内容 

查看git对象的内容：

git cat-file -p [commid id]

输入上述查看git对象后，我们能看到的内容：

• parent：表示上一次提交时的commit id
• tree：Git 中的一个基本对象，表示某个特定目录的结构。它包含了文件和子目录的信息。通过tree的commit id我们能查看到修改后的文件内容

---

修改文件

git追踪管理的其实是修改，而不是文件！

通过如下指令，可以查看是否有对暂存区的修改

git status

 

可以看到，若我仅仅是对工作区内容进行了修改，那么它会提示暂存区中的数据没有被修改！并且也会提示被修改的文件是在工作区被修改的，即modified：ReadMe(工作区中的ReadMe文件被修改)

status仅仅能表示该文件内容是否被修改，但不清楚具体修改了什么内容

Linux中可以查看暂存区和工作区之间内容的差异：

git diff [文件名]

 

---

版本回退 

什么是版本回退？

Git版本回退是指在Git版本控制系统中，将代码库的状态恢复到先前的某个提交。这个操作通常用于撤销不想要的更改、修复错误或查看历史版本。

例如：

我们git在提交version0版本时，只有一行hello，world。

之后的version1版本，我们添加了一行hello，git。此时version1中有两行的内容

通过版本回退我们能拿到version0，即只有一行hello，world时的样子

---

如何版本回退？ 

Git版本回退我们采用如下指令：

git reset [选项] [commit id]

reset进行版本回退时，本质是回退版本库中的内容 

若需要回退工作区以及暂存区的内容，那么需要我们为上述指令添加上选项

reset一共有三个选项：

• --soft
• --mixed
• --hard 

若我们reset时选择--soft选项，那么版本回退只回退的是版本库中的内容，对于工作区以及暂存区是不进行回退的 

若我们reset时选择--mixed选项，那么版本回退时既回退版本库中的内容，还会回退暂存区的内容，但工作区不会进行版本回退

若我们reset时选择--hard选项，那么版本回退时工作区、暂存区、版本库都会进行版本回退

---

表格示例 

假设我们version0版本时，文件内容为git。version1版本时，文件内容添加了 world。那么对于该文件遵循如下表格 

	工作区	暂存区	版本库
不进行reset	git world	git world	git world
--soft	git world	git world	git
--mixed	git world	git	git
--hard	git	git	git

---

版本回退时的注意事项 

对于--hard选项，我们需要谨慎使用！

• --hard选项，会回退工作区的内容，这意味着，假设有人在工作区中进行开发。那么开发的代码会直接被回退掉！

---

版本回退演示 

进行版本回退时，我们需要知道之前版本的commit id

如下图：我首先完成version0版本的提交

如下图：我完成了version1版本的提交

首先是进行版本回退之--hard的测试

如图我们会发现，testgit文件不见了，因为我们回退的版本是最先一次提交的版本，--hard选项直接把我们的工作区也回退了

如果后悔了怎么办？

只要有commit id，再次进行hard回退即可，如下：

我回退的是version1版本，此时能看到文件内容又被回退回来了！

但这种后悔药仅仅是因为我提前知道，所以提前git log获取了commit id。若我们把服务器关了，或者屏幕清了，如何能恢复呢？

使用git reflog指令可以查看到本地每一次提交时的记录

红框中的就是commit id，严格来说是commit id的一部分，但我们仍然可以使用这个commit id的一部分进行版本回退！

如下：

需要注意的是：由于实际开发中经常使用git操作，所以这些commit id不是一直保存的，系统可能会自动清理掉一些commit id，若commit id被清理，那么就没有后悔药可以吃了，所以如果发生误回退行为，请尽快操作！

---

原理 

 

如图所示，版本库中的objects对象区中会管理git对象，而所谓的版本回退就是让master指针从一个git对象指向前一个git对象。整个过程只需要改变指针的指向，所以回退操作一般是非常快的 

---

撤销修改 

什么时候需要撤销修改? 

如果我们在我们的工作区中写了很长时间代码，越写越写不下去，觉得自己写的实在是垃圾，想恢复到上一个版本

此时根据不同情况，我们可以采取不同的恢复策略

注意：以下聊的撤销修改指的是期望工作区、暂存区、版本库中都撤销修改！并且如下撤销都是基于没有进行push操作(推送到远程仓库)的前提下！

---

第一种情况：对于工作区的代码，还没有add操作 

我们期待的结果是工作区的代码都进行撤销

对于这种情况，我们有三种解决方式：

• 手动修改(不推荐)，容易手动改出bug
• git checkout -- [文件名]
• reset进行版本回退，之前说过不再赘述

对于git checkout --来说，就是回退到文件最近一次提交时的样子！其中"--"是非常重要的，若不带上"--"那么该指令是另外的含义！

如下示例：

---

第二种情况：已经进行add添加到了暂存区当中，但还没有commit 

我们期待的是工作区与暂存区的代码都进行撤销

对于这种情况我们有两种解决方案：

• 使用reset带上--hard选项一步到位直接到最近一次提交的样子
• 使用reset带上--mixed选项转化为第一种情况的样子

hard我们之前已经详细使用过，接下来我们使用mixed进行回退

mixed是默认选项，不需要显示写都可以！

同时我们不需要再去找commit id了

• 若我们需要回退到当前版本，那么commit id可以替换为HEAD
• 若我们需要回退到上一个版本，那么commit id可以替换为HEAD^
• 若我们需要回退到上一个版本，那么commit id可以替换为HEAD^^
• 以此类推....
• 这种方式也适用于--hard和--soft选项

 

---

第三种情况：工作区、暂存区、版本库中都已经添加了修改内容 

 参考第二种情况！

---

删除文件

对于工作区的文件，直接使用rm指令删除即可

对于既在工作区，又在暂存区的文件，又或者在版本库中的文件，git中提供了rm方式删除文件，git中的rm和删除工作区的rm的区别在于git提供的rm既会删除工作区中该文件，又会删除暂存区中该文件，使用了git rm后，我们直接提交一次即可

如下示例：