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/135734340
https://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，可以简单理解成如下⽰意图 :
撤销修改
如果我们在工作区写了很长时间，发现自己写的是在是垃圾，像恢复到上一个版本怎么办
情况一 ：对于工作区的代码还没有add
首先你可以自己手动删除，当然这样是有点蠢的但是也不为是一种方法，前提是你知道自己这几天到底写了什么东西进去，如果开发时间长了肯定也是记不住那么多。
Git提供了更好的方式，可以使用git checkout -- [file] 命令让工作区的文件回到最近的一次add或commit时的状态。要注意 git checkout -- [file] 命令中的 -- 很重要，切记不要省略，⼀旦省略，该命令就变为其他意思了
此时只要git checkout -- text就可以了
情况二 ：对于工作区的代码已经add了
写的垃圾代码已经add到暂存区中了怎么办？
上面知道git reset -- mixed 是可以回退版本区和暂存区中的代码
- 第一种reset + checkout --
所以这里只要 git reset --mixed HEAD 就可以让暂存区也回到当前版本状态
然后再使用上面的 git checkout -- text就可以让工作区也回退到之前状态
- 第二种reset --hard
git reset --hard HEAD 就可以了，工作区暂存区都回退到当前版本库中的状态了
情况三 ：对于工作区的代码已经add了还commit了
不要担⼼，我们可以 git reset --hard HEAD^ 回退到上⼀个版本！不过，这是有条件的，就是
你还没有把⾃⼰的本地版本库推送到远程。还记得Git是分布式版本控制系统吗？我们后⾯会讲到远程版本库，⼀旦你推送到远程版本库，你就真的惨了……
删除文件
再Git中，删除也是一个修改操作，我们实战一下，如果要删除file1怎么办？
直接rm file1呢？
这样删除没有用的，git status命令会告诉你哪些文件被删除了
此时，⼯作区和版本库就不⼀致了，要删⽂件，⽬前除了要删⼯作区的⽂件，还要清除版本库的⽂
件。
一般到这里会有两种情况：
- 确实要从版本库 中删除文件
- 不小心删错了
对于第二种情况，上面说过了需要git来恢复,删除也是修改的一种: git checkout -- file5 就好咯
对于第一种情况，很明显我们只删了工作区的内容，版本库中并没有被删除，这时候就需要git rm将文件从暂存区和工作区中删除，并且commit:
OK啦这样就行了，成功删除了file1