【武sir_B站课程】git课程笔记_07/08/09/10/11/12_代码回滚、分支、紧急修复bug、工作流

 （0）摘要

# 课程链接：

git实战（老男孩最新视频）_哔哩哔哩_bilibili

# 本文覆盖的课程内容【代码的双引号一律是引用的意思！！！】：

07_回滚

08_git命令小总结

09_初识分支

10_紧急修复线上bug的思路

11_基于分支修复线上bug的具体流程

12_命令总结和工作流

（1）回滚

# （1）首先我们新增了几个版本，那么具体使用git log 命令可以查看搭配，如下所示：

 # （2）由于带有约饭版本的功能存在违规，因而我们可以使用回滚命令，将版本回滚到上面的其中的一个版本中。比如我们回滚到短视频功能。首先要知道短视频功能的版本的commit后面的代码，即下图：

 # （3）而后，使用git reset --hard commit的值  的命令既可以回滚到想要的版本了。如图

 # （4）然后我们打开index.html可以看到，原有的约饭功能没有了，如图：

---

~~~【如果此时，约饭功能又允许上线了，那么我们要怎么样才能回到拥有约饭功能的版本呢？】

# （5）此时，如果单纯使用git log命令是看不到约饭功能的版本的，如图示：

 # （6）那么我们就需要使用git reflog 命令来查看了，如图示：

 # （7）这时，我们如果想要回到约饭功能版本的话，可以使用git reset --hard 上图横线的回退值，也就是git reset --hard ef5f4b3 。之后就能回到约饭功能版本了。如图：

（2）git命令小总结

# （1）三大区域【新】

 # （2）对于上面的三大区域的一个理解应用。比如说在index.html文件中，我们做了改动，但是还没有提交到管理中，这样我们可以使用git checkout来恢复index.html，也就是说刚才我们的改动不生效了。具体命令： "git checkout -- index.html "  。那么具体实操~~不搞。

 # （3）git reset HEAD命令的意思是将提交暂存区的文件给重新恢复到未被管区【看图理解就行】。具体命令： “git reset HEAD index.html”。具体实操~~不搞。【用多了就会了】

（3）初识分支和紧急修复线上bug的思路【由于这两节课对于理解分支有很大的帮助，所以笔记合并。】

# （1）分支。如下图描述，现在设计了一款软件，C1为第一版，C2为第二版。其中，C1中的文件有a、b、c。那么假设C2较之前的C1版本的区别只是改动了a文件为a’。那么git的生成C2的逻辑就只是把a‘保存了。而C2中的b、c选择指针的方式指向C1中的b、c文件【类似快照的感觉】。这种做法可以很大程度节约存储成本。

# （2）如果新出了第3版C3【在C2基础上改动】，那么其思路也是类似的，只是保存了C2中改动的部分，没改动的一律以指向的形式【类似快照】。

# （3）紧急修复线上bug的思路---使用分支法解决。

                1）分支。如下图分支1，这里假设C3版本之后，分别有C4和C5【也就是说C4和C5是同样是基于C3的】。二者因为要新增的功能不同，因此分开了两个支线，当最后完成后，进行整合为C6【这里是简单介绍下分支。】

                 2）紧急修复线上bug的思路。这里假设我们基于C3版本新增功能为C4版本时【还在开发中，阶段为C4_1如下图的1个月】，突然C3版本出现bug，我们不可能舍弃新开发的C4_1去退回C3版本，因此我们可以利用分支思想，来新增C5版本来修复bug

                 3)分支后合并。当修复好bug生成版本C5后，我们需要生成版本C6来将C5合并到主线上面；同理，新增的版本C4_2已经将新增功能写好时，就可以合并到C7了。【所谓主线，即术语master。就是C1、C2、C3、C6、C7。而类似于C4和C5的分支，则可以自己命名，比如C5为修bug的分支，C4为开发分支】。这里不难看出，分支起到了隔离环境的作用。如下图示。【可能有点错误。】

（4）基于分支修复线上bug的具体过程。【针对于上述的理论的实际操作】

# （1）首先是一个轮廓图。如下，找到干线【master】，即C1、C2、C3、C6、C7

# （2）那么让我们开始使用git的命令来完成吧。

                a）找到主线。使用git log 命令，查看当前的主线版本【还是在原来的db_hot/文件夹下，打开git bash】。那么我们假设有如下对应关系，即主线为C1, C2, C3, C5。

                C1: v2

                C2: 短视频功能

                C3: 约饭功能

                C5: C5

                b）查看分支。使用git branch 命令来查看当前分支。如下图，可以看到当前有master，即主线。还没有其他的分支。【*且文字标黄，说明我们当前系统处于该分支上面。主线其实就是逻辑上的主分支。】

                 c）创建分支。使用git branch 分支名，就可以创建新分支了。如下所示，我们将新创建的分支命名为dev，那么命令格式为： git branch dev

                d）将系统环境转变到新创建的分支上。使用git checkout dev来转变git的系统环境【其实就是类似隔开的一个虚拟环境，也就是说，在dev上开发，是不会影响到master的】。如下所示，那么现在就切换到了新建的dev分支上面了。

                 e）示例，在dev分支上面开发新功能的场景。如下是修改的index.html中的代码，假设新功能只完成了50%。那么此时执行git status就能看到修改后的index.html。

                f）那么我们使用git add . 把文件管理并且使用 git commit -m 'C4'来将修改后的文件生成版本为C4，也就是说我们的C4是分支的版本。如图所示。

                g）之后，我们再次执行git log 命令查看版本，如图所示。

                 h）如图所示，然后我们再使用git checkout master来切换回主线分支【下图的第一个】。此时查看index.html文件，可以发现压根没有改动。【下图的第二个】。如果想要查看到C4的话，可以继续跳回dev分支即可。

                                  

                i_1）假设现在线上紧急出bug了，而我们基于C3在开发新功能的C4版本还没完成【dev分支上】，那么我们可以切回master主线，且思路是新建一个bug分支来处理线上C3的bug。也就是说创建bug分支，使用git branch bug创建，然后使用git checkout bug切换到bug分支上面，对index.html进行修改。

                 i_2）修复完后，按基本套路完成新版本的生成，假设修复bug后的版本为C6。那么具体的操作命令流程如下。也就是说现在我们在bug分支上面完成了版本的bug修复为C6。

                i_3）把bug分支的版本C6合并到主线上。首先要切换回master分支，而后使用

git merge bug 把bug分支合并到master上面。具体的命令执行如下：

                 i_4）那么这次再看看git log 查看各个版本。显然修复后的C6被合并到了master主线中，此时可以去掉bug分支了，执行git branch -d bug就能够删掉bug分支了。

                i_5）bug修复完成后，我们再继续转而去C4版本完成后续的功能。使用git checkout dev切换到dev分支，并且找到C4分支的index.html【这里注意，C4是源于C3的，也就是说C4中并没有把修复代码合并过来。】。那么我们将新功能完成后，再切换回master主线中，合并代码。具体命令如下，但是我们发现git报了冲突。这是因为原先新增功能C4是基于C3的，但是C6是对C3bug修复的版本，然后C4中并没有修复部分的代码，因而起的冲突，这时候只能使用手动来处理了。

                 i_6）如下图，git给我们将两个有改动的地方放在了一起，并且用矩形框中的格式标注出来，因此我们需要手动来选择所需要合并的代码。结果如下图。

                 i_7）解决完冲突后，我们最后将版本进行提交。具体操作如下图，结果也如下图所示。

 （5）命令总结和工作流。

# （1）小总结。

 # （2）工作流。如下所示，就是一个最基本的工作流。其实工作流简单来说就是默认要有几个分支来完成软件的开发，比如说一个软件要有主线分支master和开发分支dev，其中主线中的C1是正式版本（稳定版本），然后dev分支的C2和C3是基于成熟版本C1来开发新功能的版本，可以理解为测试版（比如腾讯QQ的beta版本）。只有在测试版本即C3成熟时（可以理解为bug free？）才将C3合并到主线master的版本中。