Git应用详解第四讲：版本回退的三种方式与stash

最新推荐文章于 2023-08-20 15:28:11 发布

keocce

最新推荐文章于 2023-08-20 15:28:11 发布

阅读量809

点赞数 1

原文链接：https://www.cnblogs.com/AhuntSun-blog/p/12700155.html

版权

前言

米妮中文网 https://m.amini.net

前情提要：Git应用详解第三讲：本地分支的重要操作

git作为一款版本控制工具，其最核心的功能就是版本回退，没有之一。熟悉git版本回退的操作能够让你真真正正地放开手脚去开发，不用小心翼翼，怕一不小心删除了不该删除的文件。本节除了介绍版本回退的内容之外，还会介绍stash的使用。

一、版本回退

在git中永远有后悔药可吃，总是可以回到版本库的某一个时刻，这就叫做版本回退；

如上图所示：当前master分支指针指向D，通过版本回退可以使master指向C、B或A。进行版本回退的命令大体上有三种：reset、revert和checkout。下面就来一一讲解：

Ⅰ.`git reset`

1.参数

reset命令可以添加很多参数，常用的有--mixed、--soft和--hard三种。下图为一次完整提交的四个阶段：

三个参数大体上的区别为：

--mixed：为默认值，等同于git reset。作用为：将文件回退到工作区，此时会保留工作区中的文件，但会丢弃暂存区中的文件；
--soft：作用为：将文件回退到暂存区，此时会保留工作区和暂存区中的文件；
--hard：作用为：将文件回退到修改前，此时会丢弃工作区和暂存区中的文件；

下面就来详细地讲解它们的使用方法：

首先在master分支进行四次提交，每次提交在test.txt中添加一行文本信息：

`--mixed`

该参数为默认值，作用为：将文件回退到工作区中：如下图所示，将test.txt文件回退一次提交：

可以看到第四次提交对test.txt的修改操作被回退到了工作区当中，并且保留了工作区中第四次提交对test.txt所做的修改，所以工作区中的test.txt文件内容与回退前一致。

`--soft`

该参数的作用为：将文件回退到暂存区中：如下图所示，将test.txt文件回退一次提交：

可以看到第四次提交对test.txt的修改操作被回退到了暂存区当中，并且保留了工作区和暂存区中第四次提交对test.txt所做的修改，所以，工作区中的文件内容与回退前一致。

`--hard`

该参数的作用为：将文件回退到修改前：如下图所示，将test.txt文件回退一次提交：

可以看到test.txt直接回到了进行第四次提交前，此时删除了工作区和暂存区中第四次提交对test.txt所做的修改。所以，工作区变得干净了，test.txt文件内容回退到刚完成第三次提交时。

2.写法

为了方便演示reset的各种使用方法，下面的指令都采用--hard参数。

`git reset --hard HEAD^`

该命令的作用为回退一次提交：

回退后的状态为：

可以看到，该方法会同时改变了HEAD和master指针的指向；

`git reset --hard HEAD^^`

该命令的作用为回退两次提交：

回退后的状态为：

同样，使用--hard参数回退，工作区是干净的；可以看到，该方法也会同时改变HEAD和master指针的指向；

`git reset --hard HEAD~n`

该命令的作用为回退n次提交：

可以看到使用了--hard参数，回退结果符合预期，并且该方法也会同步修改HEAD和分支master指针的指向。

注意：该方式只能向前回退，不能向后回退。

上述命令中的HEAD可以更换为分支名，比如master：
git reset --hard master~n
该命令表示将master分支回退n次提交。由于HEAD始终指向当前分支，所以使用分支名和使用HEAD效果是一样的。

`git reset --hard commit_id`

该指令的作用为回退到指定的commit id的提交版本；由于commit id是不会重复的，一般只需要写前几（6）位就可以识别出来。通过commit id的回退方式既可以向前回退，也可以向后回退。如下所示，从1st commit往后回退到4th commit，其中4th commit的commit id = bdb373...。

为了熟悉该指令，我们分两种方式进行回退：使用--hard参数与使用默认参数。

使用--hard参数

从图中可以看出：通过第四次提交的commit_id: bdb373顺利地从第一次提交向后回退到了第四次提交，并且工作区干净。该方法也同时修改了HEAD和分支master的指向，具体过程为：
使用默认参数

可以看到切换回了4th commit，但是工作区的test.txt文件并没有变化；这是因为，在4th -> 1st的过程中，需要在工作区中删除test.txt文件中的2nd line、3rd line、4th line。通过默认参数--mixed，将4th commit对文件的修改回退到了工作区当中，如下图所示：

这个过程丢弃了暂存区中对文件的删除操作，但是保留了工作区中对文件的删除操作。所以，工作区中的test.txt文件仍然处于删除了三行内容的状态。

此时只需要将修改操作从阶段1移动到修改前的阶段0，即可将文件恢复到修改前的状态，并清空工作区。可以采用git restore test.txt实现：

Ⅱ.`git revert`

revert是回滚，重做的意思。不同于reset直接通过改变分支指向来进行版本回退，并且不产生新的提交；revert是通过额外创建一次提交，来取消分支上指定的某次提交的方式，来实现版本回退的。如下图所示，假如想要重做提交B，重做前与重做后的状态为：

所谓重做提交B，指的是在新建的提交B'中取消提交B中所做的一切操作。也就是说revert的思想为：通过创建一个新提交来取消不要的提交。所以，提交数会增加。

1.参数

git同样为revert提供了许多参数，常用的有以下三种。为了演示它们的作用，首先需要设置对应的测试环境：在dev分支上进行四次提交，每次提交都为test.txt添加一行内容：

`-e`

-e参数是--edit的缩写，为revert指令的默认参数，即git revert -e等同于git revert。该参数的作用为在重做过程中，新建一次提交的同时编辑提交信息。比如通过以下命令重做上述的dev2提交：

git revert f4a95

执行该指令后会创建一次新的提交来取消提交dev2所做的一切操作，并且会进入vim编辑器，编辑新提交的提交注释：

如下图所示，提交dev2为文件test.txt添加的dev2文本被取消了，并且dev分支上多了一次提交：

`--no-edit`

该参数的作用为不编辑由于revert重做，所新增提交的注释信息。如下图所示，通过：

git revert --no-edit f4a95b

重做提交dev2的过程中，并不会进入vim编辑器编辑新增提交的注释信息，而是采用默认的注释信息：Revert "dev2"：

`-n`

-n参数是--no-commit的简写形式，作用为对revert重做某次提交时所产生的修改，不进行提交，也就是不会新增一次提交；

如下图所示，这是revert指令通过新建提交B'来取消提交B的过程，分为0~4个阶段。不添加-n参数时，revert指令会产生一次额外提交B'，此时处于下图中的第3阶段。而使用-n参数时，虽然revert指令也会通过新建提交B'来重做提交B。但是，此时还处于生成提交B'的过程，还没有完全生成提交B'，也就是处于下图中的第2阶段。

这种做法的好处是，允许我们干涉revert重做过程，手动进行提交。如下图所示，通过：

git revert -n f4a95

重做提交dev2的过程中，手动暂停了重做过程。虽然提交dev2对test.txt所做的修改已被撤销，但是这一重做操作还未进行提交：

这样我们既可以修改重做过程中不满意的地方，也可以随意添加注释。修改完后，通过手动提交的方式，完成重做（REVERTING）操作：

2.写法

revert指令也有多种写法，下面介绍主要的几种。为了方便演示，下列指令都采用默认参数-e手动编辑每次新增提交的注释信息。

`git revert commit_id`

这是最常用的写法，通过commit_id精准地选择想要重做的提交。分两种情况：

情况一：重做最新一次提交，不会发生冲突。

例如：通过以下指令，重做dev分支上最新的一次提交dev2：
```
git revert f4a95b
```
首先进入vim编辑器编辑新增提交的注释信息：

随后完成重做操作，如下图所示；可见提交dev2给test.txt添加的dev2内容被删除了，并且多出一次提交，说明重做成功：
情况二：重做非最新一次提交，会发生冲突。

例如：通过以下指令，重做dev分支上的第三次提交dev1：
```
git revert dbde45
```
会出现合并冲突：

使用git mergetool指令，通过vim编辑器的工具vimdiff显示冲突文件test.txt：

回车进入vim编辑器界面，解决冲突：

解决冲突之后，手动进行一次提交，完成revert过程：
为什么会出现冲突？

通过上面的例子不难看出，revert操作生成的新提交其实是通过两次提交合并而成的。如下图所示：
- 首先，将被重做的提交dev1的前一次提交2nd复制一份，即图中的2nd'；
- 然后，将它与当前分支的最新提交dev2进行合并，由此生成revert操作新增的提交；
知道了revert操作新增的提交的由来后，就不难解释为什么会出现合并冲突了，如下图所示：

合并的两次提交中，文件test.txt的内容不一样。git不知道以哪个版本为准，自然会导致自动合并失败，需要手动合并。

`git revert HEAD`

该指令的作用为重做所在分支的最新一次提交，并且不会发生冲突：

`git revert HEAD^`

该指令的作用为重做所在分支的倒数第二次提交，会发生冲突，需要手动合并，完成重做操作：

`git revert HEAD^^`

该指令的作用为重做所在分支的倒数第三次提交，会发生冲突，需要手动合并，完成重做操作：

`git revert HEAD~n`

该指令的作用为重做所在分支的倒数第n+1次提交，会发生冲突，需要手动合并，完成重做操作。过程与上述一致，这里就不再赘述了。

总结：常用git revert commit_id这种方式。

3.撤销`revert`操作

思路很简单，再次通过revert操作取消上一次的revert操作（即所谓"负负得正"）。

操作前，dev分支上的提交记录和test.txt文件内容如下：

通过：git revert --no-edit f4a95重做提交dev2（--no-edit表示不修改新增提交的注释）：

重做后，多了一次提交，并且test.txt文件中删除了dev2这一行内容。此时，可以通过：

git revert --no-edit 582d127

重做上一次重做操作，以此达到取消上一次重做操作的目的：

如上图所示，虽然多出了一次提交，但是test.txt文件中被删除的dev2内容被恢复了，这样就撤销了revert操作。

Ⅲ.`git checkout`

1.`git checkout commit_id`

使用checkout可以进行版本回退，如直接使用：

git checkout cb214

回退到提交3rd，此时会出现如下提示：

注意到，切换后HEAD指向的不再是master分支，而是cb214...即第三次提交，查看历史提交记录：

可看到只有3次提交，什么意思呢？如下图所示：

通过git checkout让HEAD指针指向了第3次提交，可以将它想象为一个新的分支。但是却没有实际创建分支，即此时head指向的由提交1~3组成的commit对象链条处于游离状态；

接着，在HEAD还指向游离的提交节点3的基础上对文件做出新的修改：

此时如果我们切换回master分支，会出现下列错误

提示显示：如果没有保存就从游离的提交上切换到master分支，这一修改就会被checkout命令覆盖。我们可以在切换前进行一次提交操作：

此时的状态为：

在游离的Commit对象链中进行了一次提交之后，再次通过：git checkout master切换到master分支：

提示大意为：如果没有任何分支指向刚才在游离的Commit对象链中进行的提交，那么该提交就会被忽略。此时的状态如下图所示：

如果想要创建一个分支保存（指向）这条游离的Commit对象链，现在就是很好的时机。根据上述提示的命令：

git branch mycommit  c4d5cc3

创建指向commit_id为c4d5cc3的提交（即上述的提交节点5）的分支mycommit：

由此游离的commit对象链得以被新分支所指向，并得到了保存，此时的状态如下图所示：

总结：

通过checkout进行版本回退会造成游离的提交对象链，需要额外创建一个分支进行保存；

因此，使用checkout进行版本回退的思路为，先切换到想要回退的提交版本，再删除进行版本回退的分支dev。最后，创建一个新的dev分支指向游离的提交对象链，完成分支dev的版本回退，简称"偷天换日"；

只要有分支指向，提交就不会被丢弃。

Ⅳ.`revert`与`reset`的选择

由于checkout会造成游离的提交对象链，所以，一般不使用checkout而是使用reset和revert进行版本回退：

revert通过创建一个新提交的方式来撤销某次操作，该操作之前和之后的提交记录都会被保留，并且会将该撤销操作作为最新的提交；
reset是通过改变HEAD和分支指针指向的方式，进行版本回退，该操作之后的提交记录不会被保留，并且不会创建新的提交；

在个人开发上，建议使用reset；但是在团队开发中建议使用revert，特别是公共的分支（比如master)，这样能够完整保留提交历史，方便回溯。

Ⅴ.回退方法汇总

版本回退主要有三大方式：reset、revert和checkout，各方式的比较如下：

方法	效果	向前回退	向后回退	同步修改`HEAD`与分支指向
`git reset --hard HEAD^`	往前回退`1`次提交	能	否	是
`git reset --hard HEAD^^`	往前回退`2`次提交	能	否	是
`git reset --hard HEAD~n`	往前回退`n`次提交	能	否	是
`git reset --hard <commit_id>`	回退到指定`commit id`的提交	能	能	是
`git revert HEAD`	重做最新一次提交	能	否	是
`git revert HEAD^`	重做倒数第二次提交	能	否	是
`git revert HEAD^^`	重做倒数第三次提交	能	否	是
`git revert HEAD~n`	重做倒数第`n+1`次提交	能	否	是
`git revert commit_id`	重做指定`commit_id`的提交	能	能	是
`git checkout commit_id`	回退到指定`commit id`的提交	能	能	否

从上表可知，只有下列三种方式可以自由地向前向后回退：

git reset --hard commit_id
git revert commit_id
git checkout commit_id

但是，使用checkout进行回退会出现游离的提交，需要创建一个新分支进行保存，所以不常用。

二、`git stash`

1.`git stash`的作用

git stash指令的作用为：对没有提交到版本库的，位于工作区或暂存区中游离的修改进行保存，在需要时可进行恢复。具体应用场景如下：

在master分支进行两次提交：1st和2nd，随后创建并切换到dev分支。在dev分支上进行一次提交（dev1），此时两分支的状态为：

随后在dev分支上给文件test.txt添加一行dev2，但是不提交到暂存区，直接切换到master分支，会出现如下错误：

图中显示的错误大意为：在dev分支上的修改会被checkout操作覆盖。下面我们来看看，将dev分支上的这一修改操作添加到暂存区后，再切换分支，是否还会出现同样的问题：

可见还是会出现该错误，这初步验证了位于工作区和暂存区中的修改都会被checkout操作覆盖的结论。原因如下图所示：

虽然在dev分支上修改了文件，但是没有将这一修改操作进行提交。这样就不会产生提交节点，就如上图所示，修改dev2是游离的，在切换分支的时候会被丢弃。

这种情况在日常开发中很常见，当在develop分支上开发新功能的时候，master分支出现紧急情况需要切换回去进行修复。但是，当前分支的新功能还没开发完全，贸然切换分支，原来开发的内容就会因被覆盖而丢失，怎么办呢？

有人可能会说进行一次commit不就可以了吗？确实可以。但是，这样不符合提交的代码就是正确代码的原则。更好的解决方法为使用git stash，如下图所示：

可见git stash可以将当前dev分支上，位于在工作区或暂存区中的修改，在未提交的情况下进行了保存；并且将分支回退到修改前的状态，保存过后，就可以很顺畅地切换回master分支了。

图中的WIP（working in progress）表示的是正在进行的工作；

当我们在master分支上完成了工作，再次切换回dev分支时，查看test.txt文件：

发现切换分支前所做的修改dev2消失了，这是为什么呢？

其实，上面通过git stash将dev分支上工作区或暂存区中的修改，提交到了stash区域进行保存，并将dev分支回退到修改前的状态。如下图所示：
切换到master分支时test分支上的修改依旧会被覆盖。所以，再次回到dev分支时需要从stash区域中恢复切换分支前保存的修改；

怎样恢复通过git stash保存到stash中的修改呢？可以通过：

git stash list

查看该分支上被stash保存的修改：

继续给test.txt文件添加内容：dev3，并通过以下指令保存修改的同时添加注释：

git stash save '注释'

首先，通过上述命令可以修改stash中存储修改的备注信息；
其次，虽然在test分支上进行了两次修改，但是使用git stash保存修改后，文件test.txt并没有实际被修改；

2.恢复`stash`存储的修改

方法有很多，主要有以下三种：

`git stash pop`

如图所示，通过上述命令将stash中存储的最新一次修改恢复了。相信你已经发现了，stash与栈非常类似：先保存的修改，排在最后，序号最大；后保存的修改，排在最前，序号最小；

恢复了最新一次修改后，再次查看stash：

可以看到存储的修改只剩下一条了，由此可推断出git stash pop作用为：

第一：恢复stash中存储的最新一次修改；
第二：将该修改从stash中删除；

`git stash apply`

如上图所示，使用该指令时发生了合并冲突。这是因为，stash中保存的每一次修改代表的都是一个版本。

如上图所示，在test分支上，进行第一次修改后，通过git stash将该修改作为修改0保存到stash中，此时分支中的文件并没有发生改变；
进行第二次修改后，通过git stash将修改作为修改1保存到stash中，分支中的文件依旧没有发生改变；此时的stash中相当于保存着同一分支上两个修改后的版本；
此时通过git stash pop取出修改0，与test分支进行合并；再通过git stash pop取出修改1，再次与test分支进行合并，两个版本合并自然会产生冲突。