Git的原理和使用（二）

1. git的版本回退

        之前我们也提到过，Git 能够管理⽂件的历史版本，这也是版本控制器重要的能⼒。如果有⼀天你发现 之前前的⼯作做的出现了很⼤的问题，需要在某个特定的历史版本重新开始，这个时候，就需要版本 回退的功能了。 执⾏ git reset 命令⽤于回退版本，可以指定退回某⼀次提交的版本。要解释⼀下“回退”本质是 要将版本库中的内容进⾏回退，⼯作区或暂存区是否回退由命令参数决定：

当前我们的readme文件：

 hello git                                           v1.0
shenmengyao he yuanyiqi             v2.0

        git reset指令格式：git reset [--soft | --mixed | --hard] [HEAD] ，其本质是回退的是版本库的内容；

         如上图直接回退到第一个版本，但是我们现在想回到第二个版本的时候，指令如下：输入最开始的commit id；

        我们虽然进行回退到最初版本，但是依旧能够复原，主要是能够知道并使用最开始和最末尾的版本号，但是一旦服务器突然关闭或者清屏，导致我们回到最初版本之后没有后期版本的commit id；

        我们就使用git reflog；该指令能够看出我们的提交命令， 

        前面的黄色部分就是commit id，虽然有点短，但是我们依旧可以使用这些数字id来回退到我们希望的版本；

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

        所以我们的所谓版本回退仅仅是master指向不同的commit id，每一个id都对应一个git对象，里面都存的是是文件的内容；

2. 撤销修改

        情况⼀：对于⼯作区的代码，还没有 add

        情况二：已经 add ，但没有 commit

        情况三：已经 add ，并且也 commit 了

如下图所示：

 情况一：

        1、手动操作

        2、git checkout -- Readme

如下所示：

情况二：

        git reset HEAD Readme，回退到当前版本，就是暂存区和当前的版本库保持一致，此时只有工作区还有内容；

        接下来使用：git checkout --   Readme，使得工作区也变干净；

情况三：

git reset --hard Headme^

        回退到上一个版本；

3.删除操作

1、rm file3

        该命令指示将工作区中的文件进行删除；

2、将该删除操作添加到暂存区中：git add file3

3、将该删除操作提交到版本库中：git commit -m "delete file3" 

        简化步骤到两步：

1、git rm file2

2、提交

 4.分支管理

   4.1 分支理解

        分⽀就 是科幻电影⾥⾯的平⾏宇宙，当你正在电脑前努⼒学习 C++ 的时候，另⼀个你正在另⼀个平⾏宇宙⾥ 努⼒学习 JAVA。

        如果两个平⾏宇宙互不⼲扰，那对现在的你也没啥影响。不过，在某个时间点，两个平⾏宇宙合并 了，结果，你既学会了 C++ ⼜学会了 JAVA

对于git的树形结构，head指针指向master分支如下：

        head指针指向master分支，master指向当前该分支（主线）最新一次git提交的commit id（git对象的索引）上；

        

4.2 创建分支

        在新创建的分支上进行提交内容，最后合并该分支；

git branch

        //查看当前本地仓库的分支；

        head指针不仅可以指向master分支，也可以指向其他分支，head指向的分支才是当前工作的分支；

        git branch dev

1、创建dev分支；

        此时我们的指针依旧指向的master分支；

        tree .git // 查看当前的分支：

        此时刚创建完成dev分支后，master和dev两个分支都指向的最新提交的git对象；

2、切换到dev分支

        git checkout dev

        此时head指向的是dev分支；

        我们在dev分支中修改readme文件，添加提交操作之后，切换到master分支，观察readme文件，发现和之前的文件相比没有发生变化；

        接着切换到dev分支，我们的提交文件操作确实成功了，点击查看dev分支指向的id

        cat .git/refs/heads/dev

        查看当前索引所在的信息：

        当前分支节点和前分支节点关系如下：

3、合并

        查看当前所在分支并确保在master分支上；合并指令：

        git merge dev

        此时我们的master里面存储的dev分支提交的id，合并之后该id进入到master里面了；

4.3 删除分支

 git branch -d dev

        //我们只能在master分支上来进行删除其他分支的操作；

4.4 分支冲突

        首先在master分支对进行修改为aaa master；

        其次切换到dev分支进行修改aaa dev；然后在master分支上进行提交，此时我们不知道提交完成后保留那一句？

        一行指令完成创建和切换分支：

        git checkout -b dev1

 

此时的本地仓库的分支如下所示：

        开始合并：

        我们发现会有报错信息；

        上面两部分代码是冲突代码，所以才会放在特殊符号里面；git没办法帮我们解决这两部分代码，所以只能自己手动解决；

        

        在master分支上打开该文件进行删除不必要的文件，如上图所示：

        此时我们依旧要进行add和commit操作；

  

        此时的仓库分支如下所示：

        此时master分支指向合并之后最新提交的一次id；但是dev1指向的id依旧是之前dev最新提交的一次id；

        当出现merge冲突的时候，只能进行手动操作解决，且最后还要进行一次add和commit操作；

        git log --graph --pretty=oneline --abbrev-commit

        //该指令查看不同分支进行一些列操作的图状记录：

        其中红色部分是master分支；

ps：to be continued！！！

本文封面来自snh48的杨冰怡！！！