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/135734340icon-default.png?t=N7T8https://blog.csdn.net/Obto_/article/details/135734340


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

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

Git的管理操作_第1张图片

Git的管理操作_第2张图片

  • 图中蓝色为工作区,右侧肉色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:

查看历史提交记录

Git的管理操作_第3张图片

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

 

Git的管理操作_第4张图片

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

查看.git文件: 

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

Git的管理操作_第5张图片

不难发现一些黄色字符就是这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 命令来查看版本库对象的内容

Git的管理操作_第6张图片

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

 

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

再用git cat-file -p查看

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

使用场景--2:

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

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

Git的管理操作_第7张图片

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

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

git status:

 

Git的管理操作_第8张图片

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

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

git diff:

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

 

Git的管理操作_第9张图片

 也可以用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

Git的管理操作_第10张图片

对他第二次修改并提交:

新增一行insert:hello csdn

Git的管理操作_第11张图片

第三次修改并提交:

将insert:hello csdn改成insert:hello world

Git的管理操作_第12张图片 

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

退回到v2版本:

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

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

Git的管理操作_第13张图片

退回到v1版本:

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

Git的管理操作_第14张图片

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

后悔了咋办:

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

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

git reflog:

Git的管理操作_第15张图片

 发现了我们第三次的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,可以简单理解成如下⽰意图 :

Git的管理操作_第16张图片

 


 

撤销修改 

 如果我们在工作区写了很长时间,发现自己写的是在是垃圾,像恢复到上一个版本怎么办

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

首先你可以自己手动删除,当然这样是有点蠢的但是也不为是一种方法,前提是你知道自己这几天到底写了什么东西进去,如果开发时间长了肯定也是记不住那么多。

Git提供了更好的方式,可以使用git checkout -- [file] 命令让工作区的文件回到最近的一次add或commit时的状态。要注意 git checkout -- [file] 命令中的 -- 很重要,切记不要省略,⼀旦省略,该命令就变为其他意思了

Git的管理操作_第17张图片

此时只要git checkout -- text就可以了

Git的管理操作_第18张图片

 情况二 :对于工作区的代码已经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的管理操作_第19张图片

此时,⼯作区和版本库就不⼀致了,要删⽂件,⽬前除了要删⼯作区的⽂件,还要清除版本库的⽂
件。

一般到这里会有两种情况:

  • 确实要从版本库 中删除文件
  • 不小心删错了

对于第二种情况,上面说过了需要git来恢复,删除也是修改的一种: git checkout -- file5 就好咯

对于第一种情况,很明显我们只删了工作区的内容,版本库中并没有被删除,这时候就需要git rm将文件从暂存区和工作区中删除,并且commit:

Git的管理操作_第20张图片

OK啦这样就行了,成功删除了file1 

你可能感兴趣的:(Git,git,工作区,暂存区,版本库,基本版本操作)