Git的管理操作

前言

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

小结：

使用场景--1：

git log：

查看.git文件：

使用场景--2：

git status：

git diff：

进行提交：

总结：

版本回退

退回到v2版本：

退回到v1版本：

后悔了咋办：

git reflog:

为什么版本回退这么快？

撤销修改

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

情况二：对于工作区的代码已经add了

情况三：对于工作区的代码已经add了还commit了

删除文件

前言

上一篇文章分享了如何安装Linux，作为本章的前提即是已经安装好了Git

https://blog.csdn.net/Obto_/article/details/135734340https://blog.csdn.net/Obto_/article/details/135734340

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

工作区：就是在你写代码的那个目录就叫工作区
暂存区（stage \ index）：一般放在.git目录下的index文件(.git/index) 中，我们把暂存区有时也叫做索引
版本库（repository）：又名仓库。在你的工作区有一个隐藏目录.git，他不算工作区，而是Git的版本库。这个版本库里面的所有文件都可以被Git管理起来，每个文件的、修改、删除，Git都能帮你追踪，以便于任何时刻都可以定位到历史版本，以便于在将来的某一时刻还原“”

图中蓝色为工作区，右侧肉色windows版本库。Git的版本库中存了很多东西，也包括暂存区
在创建Git版本库的时候，Git会为我们创建一个唯一的master分支，以及一个指向master的一个指针叫HEAD（分支在后文讲述）
当对工作区的修改，或者新增的文件执行git add命令时，暂存区目录树的文件索引会被更新
当执行提交git commit时，master分支会做相应的更新，可以简单理解为暂存区的目录树才会真正被写到版本库中

小结：

1. 不是在.git下创建的文件git就会帮你管理，需要add 进暂存区，再commit提交到版本库

使用场景--1：

在.git目录下创建一个ReadMe文件，可以使用git将他添加到暂存区中：

添加⼀个或多个⽂件到暂存区： git add [file1] [file2] ...
添加指定⽬录到暂存区，包括⼦⽬录： git add [dir]
添加当前⽬录下的所有⽂件改动到暂存区： git add .

再使⽤ git commit 命令将暂存区内容添加到本地仓库中：

提交暂存区全部内容到本地仓库中:? git commit -m "message"
提交暂存区的指定⽂件到仓库区： git commit [file1] [file2] ... -m "message"

这里注意：git commit 的 -m 不能省略要跟上描述本次提交的message，message是由用户自己填写，message的内容不能马虎，要认真填写，这对后面的版本控制至关重要

到目前为止已经能够将代码提交到本地仓库了，可以使用git log 来看看提交记录

git log：

查看历史提交记录

如果觉得输出的信息太多了，可以加上--pretty=oneline 参数：

黄色的那些字符则是我们每次提交的commit id（版本号），Git的commit id不是一个递增的小数字，而是SHA1计算出来的一个非常大的数，用16进制表示

查看.git文件：

仔细观察这里面的object中的数字和上面的黄色版本号

不难发现一些黄色字符就是这object目录下的一细节文件目录、文件。

index ：这里就是我们的暂存区，add后添加到这里的
HEAD：这里就是我们这默认指向master分支的指针

这里head 指向的就是一个版本号，跟上面对比就知道，这个就是当前最新的版本号

（git log 后第一行的版本号就是仓库最新的版本号commit id）

object：git的对象库，里面包含了创建各种版本库的对象及内容。当git add命令时，暂存区的目录树就会被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新对象中，就位于.git/objects 目录下

查找object时要将commit id 分成2部分，其前2位是⽂件夹名称，后38位是⽂件名称。找到这个⽂件之后，⼀般不能直接看到⾥⾯是什么，该类⽂件是经过 sha （安全哈希算法）加密过的⽂件，好在我们可以使⽤ git cat-file 命令来查看版本库对象的内容

会发现这其中还有一个tree属性，我们同样使用git cat-file -p 来看看

发现ReadMe文档也有对应的：3a1562f2c7d124bf1de50fb61265a970438772b0

再用git cat-file -p查看

就可以发现我们对ReadMe的修改都被记录下来了！！

使用场景--2：

Git⽐其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，⽽⾮⽂件。什么是修改？⽐如你新增了⼀⾏，这就是⼀个修改，删除了⼀⾏，也是⼀个修改，更改了某些字符，也是⼀个修改，删了⼀些⼜加了⼀些，也是⼀个修改，甚⾄创建⼀个新⽂件，也算⼀个修改。

此时对ReadMe文件进行一次修改：

此时仓库中的ReadMe和工作区的ReadMe就不同了，我们新增了一行。

那么如何查看当前仓库的状态呢？

git status：

上面的结果告诉我们，ReadMe被修改过了，但是还没有添加完成与提交

目前我们只知道文件被修改了，但是哪里被修改了还不知道

git diff：

查看工作区和暂存区的差异：

也可以用git diff HEAD -- [file]命令查看版本库和工作区的差异

进行提交：

这时候知道了我们对当前中工作区做了什么修改，才敢add和提交。接着就像上面走提交那一套

总结：

index：暂存区，git add后其中内容会新增
HEAD：默认指向master分支的一个指针
refs/heads/master:文件里保存当前master分支的最新commit id
objects:包含创建的各种版本库对象及内容，可以理解放了git维护的所有修改

版本回退

之前我们也提到过，Git?能够管理⽂件的历史版本，这也是版本控制器重要的能⼒。如果有⼀天你发现之前前的⼯作做的出现了很⼤的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本回退的功能了。

执行git reset 命令⽤于回退版本，可以指定退回某⼀次提交的版本。要解释⼀下“回退”本质是
要将版本库中的内容进⾏回退，⼯作区或暂存区是否回退由命令参数决定：

--mixed为默认选项，使用时可以不带参数。该参数将暂存区的内容退回为指定提交版本内容，工作区保持不变
--soft参数对工作区和暂存区保持不变，只是将版本库回退到某个版本
--hard参数将暂存区与工作区都退回到指定版本。切记工作区代码为提交的时候不要做这个操作，这会导致工作区的代码回滚，也就是未提交的代码就找不回了，此方式要慎重
HEAD说明
- 可以直接commit id
- HEAD 表示当前版本
- HEAD^表示上一个版本 HEAD^^表示上两个版本，以此类推

下面演示一下：

首先创建一个text文件:

对他第一次修改并提交:

新增一个insert:hello every body

对他第二次修改并提交:

新增一行insert:hello csdn

第三次修改并提交：

将insert:hello csdn改成insert:hello world

可以git log查看一下历史版本记录，最新的三个版本和上面一一对应

退回到v2版本：

如果我们在提交完version3后，发现version3编写错误，想回退到version2，重新基于version2开始编写。由于我们在这⾥希望的是将⼯作区的内容也回退到 version 2 版本，所以需要⽤到 --hard 参数，⽰例如下：

git reset --herd HEAD^ ：退回到上一个版本也就是version2版本，刚新增了hello csdn的版本

退回到v1版本：

像上面一样当然可以，但是这里使用另一种方式：

同样退回到v1的版本，也就是刚刚新增hello everybody的时候

后悔了咋办：

如果版本回退之后后悔了怎么办，此时git log可能已经查不到之前版本的commit id了

如果终端没有clear的话，或许之前的git log还能存在第三次提交的commit id，如果没有的话Git还提供了一个git reflog命令能够补救一下，该命令用来记录本地的每一次命令

git reflog:

发现了我们第三次的commit id ，第三次我们修改了hello csdn变成hello world，这里就有第三次的commit id :c665921

这时候就可以git reset --hard c665921

sui

虽然这种方式能够补救一下，但是随着我们本地git命令越来越多，这种信息肯定是会被冲掉的

为什么版本回退这么快？

Git在内部有个指向当前分⽀（此处是master）的HEAD指针， refs/heads/master ⽂件⾥保存当前 master 分⽀的最新 commit id 。当我们在回退版本的时候，Git仅仅是给 refs/heads/master 中存储⼀个特定的version，可以简单理解成如下⽰意图 :