【Git】Git的基本操作

前言

    Git是当前最主流的**版本管理器**，它可以控制电脑上的所有格式的文件。

    它对于开发人员，可以管理项目中的源代码文档。（可以记录不同提交的修改细节，并且任意跳转版本）

    本篇博客基于最近对Git的学习，简单介绍一下Git本地仓库的组成和基本操作（add、commit提交操作；log查看提交日志；reset回退版本等操作...）

    注意：当前我使用的centos7.6 云服务器下演示。 

一、Git的安装和本地仓库

1.git的安装和版本查看

    通过代码：git --version 查看当前git版本，再决定是否进行安装。

     如果没有就需要进行安装，在Linux下通过指令：sudo yum install -y git(默认当前你的用户存在管理员权限)

    如上便就安装成功。 

2.git本地仓库初始化与配置

    我们需要对git创建一个专门的仓库，git才能对仓库下的文件进行版本管理，而不是对于任意的文件。这里的“仓库”自然指的就是文件夹了。

    比如当前我创建一个test文件夹为git的本地仓库，进入test后，git就可以对其进行初始化和配置工作了。

**命令：git init **

** 初始化git仓库。**

    会以当前目录作为git的本地仓库，本地仓库下的文件可以收到git版本管理。

    会新增隐藏文件夹.git。内部存在很多文件，它们是用来追踪管理Git仓库的，记住不可修改里面的内容。

    现在，我在test文件夹内，执行此命令，可以看到隐藏文件夹，tree现实其目录树可以看到很多文件。（里面很多文件我们之后会讲到）

     初始化后别忘了配置，git仓库存在一些配置：name和email，后续会用到：

命令：git config [--global] user.name "名字"、git config [--global] user.email "email地址"

    配置git仓库的名字和email地址。

命令：git config -l

    可以查看当前本地仓库的配置项目。

命令 git config [--global] --unset [user.name|...]

    删除对应的config属性。

--global:

    上述命令中的[--global]可选项表明全局属性，即在当前主机的所有git本地仓库生效，如果是对应的全局生效，那么unset重置时也需要加上全局属性。

    这里随便配置一下用户为qihai，邮箱为[email protected](现编，和本篇博客后续操作无关)。

    现在将qihai删除，换成QiHai：

    现在试着将名字修改为qihai，全局模式设置，正常删除能删除么。

    此时加上全局选项删除才有效，删除后在普通将配置项修改为qihai：

3.认识本地仓库中的工作区、暂存区、版本库

    在具体操作git之前，我们需要认识工作区、暂存区、版本库这三个东西，后续我们操作的时候会更简单易懂的去理解。

    可以看到，在Git下管理我们的文件，首先需要在工作区添加到暂存区（add），其次在将暂存区的内容添加到HEAD指向的master中（commit），此时我们的Git才真正管理了工作区中的文件。 

    我们每次修改的文件，当提交到版本库中时，Git都会为其维护一个git对象，并且放在了object对象库下，其他区域内存放的就是指针。那么何为**修改**呢？

对于修改的理解就是一切对文件改动的地方：

1.删除、创建

2.增加内容、删除内容

简而言之：新增、修改、删除被称作修改。

二、工作区文件提交到版本库管理

1.将工作区的文件添加到暂存区中

    我们在当前Git本地仓库（工作区-除开.git文件外的地方）创建一个ReadMe文件，里面添加一行：Hello Git！

    现在将它提交到暂存区中。

命令：git add 文件名1 文件名2 ...

    这样可以批量或者单独添加一个多个文件到暂存区中去。

命令：git add .

    .是当前目录下的一个隐藏文件.，表示此目录下的全体文件，这样就可以一次性将工作区的文件添加到暂存区中。

    此时观察.git的目录可以发现已经创建出了index目录，说明已经为此次添加的工作区文件内容创建了git对象。

2.将暂存区内提交到HEAD指向的master中去

    将暂存区提交到master中去，此时对应的文件成功被Git管理了起来。

命令：git commit -m "本次提交的细节内容"

    将暂存区提交到版本库中去，此时文件被Git管理了起来。

3.打印从近到远的提交日志

    我们可以打印出最近的提交日志。

命令：git log

    打印出最近的Gitcommit提交日志。

命令：git log --pretty=oneline

    打印一行漂亮可观的提交日志。

    这里需要对日志中的内容进行阐释：

commit：是生成的hash-id，后续简称commit_id。

    一个commit_id指向的是一个git对象，也就是在add后创建的此次修改的git对象，保存此次提交的工作区修改数据。 

    一个id，比如：96cbd6922eaa24d8a28a8756b90ecf55cc06c15e。其中前两位96表示在object下的文件夹名，而cbd6922eaa24d8a28a8756b90ecf55cc06c15e就是保存的对象名。

​​​​​Author：为提交人的name和email。

Date：提交时间

下面的就是提交的细节信息

     现在我在工作区新增三个文件：file1，file2，file3.我现在一次性添加到暂存区并且提交。

    此时可以漂亮的打印日志查看：

    可以看见，此时只是打印出了commit-id和提交的细节内容，可以更加方便的进行查看。 

4.查看git对象中的内容

    那么对于git对象我们可以查看吗？当然可以，Git为我们提供了查看对应commit-idGit对象的命令。

命令：git cat-file -p commit-id

    -p是打印文件内容。

    此命令就是显示对应commit-id的Git对象内容。

    比如，现在我查看第一次提交的commit-id的内容：

    就可以看到与这次提交的相关信息，其中，我们当前可以关心的是tree，tree里存放的commit-id就是这次我们实际修改的工作区文件内容：

5.提交与.git相关的细节内容

    我们实际操作后其实关心的就是两个命令：add、commit。那么如何和我们的底层联系起来呢？

    首先add操作后如果存在文件修改，那么会创建index作为暂存区，并且将工作区的内容提交到index中去。（之前add后展示的有）

    那么现在从暂存区提交到HEAD中的指向区域，那么这个HEAD里到底是什么呢？

    可以看到，HEAD当前的指向就是.git目录下的refs/heads/master。那么master中存储的是什么呢？

    可以发现，master中存的就是最近一次的commit-id。对应的就是git文件，维护在Object对象库中的。 

    由此，我们可以简单总结一下：

**index**：暂存区，放add新增的内容。
 **head**：指针，指向ref: refs/heads/master
 **master**：存放的是最新一次的commit id。->git对象，git对象维护到对象库中，查看git维护的文件。
 需要注意：commit只是将暂存区内的内容写入到版本仓库中的。

三、查看修改文件细节

    那么现在还有一个现实操作上的问题。就是我现在正在工作区中工作，我如何去查看当前工作区的文件和我版本库中当前版本的差异呢？

命令：git status

    查看当前Git仓库状态。

    即将当前Gitmaster存储的版本和暂存区、工作区的文件进行对比，查看差异。

    在当前提交完毕的情况下查看自然没有任何区别：

    现在我将ReadMe文件新增一行：Hello, Git and Linux!

（注意echo的追加重定向>>本身是自动追加下一行，不用带""，如果带""后面的!会识别错误，注意踩坑）

    此时查看就能发现差异：

    可以发现，此时就是提示我们当前工作区的内容并没有添加到暂存区内（staged就是暂存区和index同样叫法）

     但是这里也只是大致的提示，我们可以详细查看暂存区和工作区的细节区别：

命令：git diff [HEAD] 文件名

    显示暂存区和工作区之间的详细差异。

    其中存在改动前（---）、改动后（+++）

    对于@@中的内容，-表示改动前，+表示改动后，数字具体表示从多少行开始，后面是连续的多少行。

    @@下面的修改内容+表示新增，-表示减少。

    加上HEAD 可以查看版本库和工作区之间的区别

     如果add后但是还没commit可以看到版本库和工作区之间的细节差异：

四、版本回退功能

1.版本常规跳转

    这是Git的重要功能之一，也是版本管理器最核心的部分。

    在我们提交的几个版本中，如果能够任意回退版本就能很方便我们的工作。

命令：git reset [--soft | --mixed | --hard] id

    回退到指定commit-id的版本。

    选项区别：

            1.soft：只回退版本库的内容

            2.mixed：版本库和暂存区进行回退。-默认选项

            3.hard：回退所有内容（工作区、暂存区、版本库）。

                    谨慎使用，容易造成数据丢失。

    id：可以是commit-id，也可以是git reflog中的部分id（后续介绍git reflog）

           id也可以是HEAD，表示当前Msater存储的上一个版本，HEAD^就是上上个版本，^可以不断增多，依次类推。

    在上面的示例中，我们有三个版本：

    现在，我想让全体跳转到第一个版本：

    可以发现，版本成功回退成功，并且此时我们打印日志会发现一件惊奇的事情：

    日志也是回退了的。那是不是把前两次的git文件删除了呢？那想回到之前的版本怎么办？

    别急，Git记录的修改文件并没有删除，我们可以利用之前的Git日志找到之前的提交版本commit-id即可，然后就可以回到我们的第三个版本：

2.查看所有提交的git命令

     那么如果此时我们找不到了之前版本日志，但是已经回退了版本怎么办？如何找到历史版本呢？（这里为了演示先回退到第一个版本）

命令：git reflog

    记录本地的每次的Git执行命令，不会随着版本回退得到修改。

    里面存在的一部分commit-id，使用reset一样可以进行回退。 

     可以发现，虽然一开始的log文件没了，但是我们还有rflog的救命稻草存在，按照部分commit-id使用reset进行回退即可。

3.撤销修改

    有些时候，我们在工作区工作，比如修改了两三天了，但是发现还是不行，想回退到一开始重新写，那么这个时候需要撤销修改。

    如果此时我们人工的去修改，会非常好时间并且还能把以前的代码给删了。

    Git为这样的操作提供了方案（基于历史的版本）

    对于三种工作区的操作，我们又可以将上述问题分解为如下的几种情况：

1.未进行add操作

命令：git checkout -- 对应文件

    此时会将工作区撤回到最近一次的add操作。

    比如目前我对ReadMe文件随便增加了一行数据，没有add操作。

    现在直接对工作区回退到上次add操作即可：

2.进行了add操作但是没commit操作

命令：git reset [--mixed | --hard] HEAD

    进行版本回退操作，选择mixed只对暂存区和版本库进行回退，对于工作区可以采用第一种，要么hard全部回退到上一次版本。

    结合上面的举的例子，现在我add了，但是没有commit。

    现在我先将暂存区和版本库回退到上个版本：

    然后在采用1的操作即可：

3.进行了commit操作，但是没有进行push操作

命令：git reset [--mixed | --hard] HEAD^

    进行版本回退操作，选择mixed只对暂存区和版本库进行回退上上个版本，对于工作区可以采用第一种，要么hard全部回退到上上次版本。

    结合上面的例子，这次我commit提交到了版本库中，但是没有push到远程仓库（后面的概念，以后会提到，这里只需理解没有进行此操作即可）

    实际上，这里也就是版本回退了。

五、对版本库文件的删除

    如果，我们相对Git仓库下的文件机械能删除，并且想要被Git管理，一般是如下的步骤：

    1删除文件，2add到暂存区，3commit提交到版本库。完成对文件的删除。

    存在一个命令可以简化12步骤（将其结合在一起）

命令：git rm 文件名

    会删除对应文件，然后add到暂存区内。

    此时就可以完成对管理文件的删除。