AhuntSun

# 第四讲：版本回退的三种方式与stash

# 前言

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

# 一、版本回退

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

image-20200406144058526

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

# Ⅰ.git reset

# 1.参数

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

image-20200412192613526

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

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

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

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

image-20200406164503683

# --mixed

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

image-20200412194811197

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

# --soft

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

image-20200412195321082

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

# --hard

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

image-20200412205112201

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

# 2.写法

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

# git reset --hard HEAD^

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

image-20200406164628192

回退后的状态为：

image-20200406164713774

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

# git reset --hard HEAD^^

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

image-20200406170323254

回退后的状态为：

image-20200406170352024

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

# git reset --hard HEAD~n

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

image-20200406203027868

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

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

上述命令中的HEAD可以更换为分支名，比如master：

git reset --hard master~n
1

该命令表示将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参数

    image-20200406193422130

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

    image-20200414171228274

  • 使用默认参数

    image-20200406193005200

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

    image-20200406202451310

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

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

    image-20200406202716247

# Ⅱ.git revert

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

image-20200413234440432

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

# 1.参数

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

image-20200414000404304

# -e

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

git revert f4a95
1

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

image-20200414115052089

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

image-20200414114945783

# --no-edit

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

git revert --no-edit f4a95b
1

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

image-20200414114748865

# -n

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

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

image-20200414002942670

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

git revert -n f4a95
1

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

image-20200414120436217

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

image-20200414121147251

# 2.写法

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

# git revert commit_id

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

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

    例如：通过以下指令，重做dev分支上最新的一次提交dev2：

    git revert f4a95b
    1

    首先进入vim编辑器编辑新增提交的注释信息：

    image-20200414135326937

    随后完成重做操作，如下图所示；可见提交dev2给test.txt添加的dev2内容被删除了，并且多出一次提交，说明重做成功：

    image-20200414140040443

  • **情况二：**重做非最新一次提交，会发生冲突。

    例如：通过以下指令，重做dev分支上的第三次提交dev1：

    git revert dbde45
    1

    会出现合并冲突：

    image-20200414140502098

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

    image-20200414140645448

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

    image-20200414141354304

    解决冲突之后，手动进行一次提交，完成revert过程：

    image-20200414142323103

  • 为什么会出现冲突？

    通过上面的例子不难看出，revert操作生成的新提交其实是通过两次提交合并而成的。如下图所示：

    image-20200414143430837

    • 首先，将被重做的提交dev1的前一次提交2nd复制一份，即图中的2nd'；
    • 然后，将它与当前分支的最新提交dev2进行合并，由此生成revert操作新增的提交；

    知道了revert操作新增的提交的由来后，就不难解释为什么会出现合并冲突了，如下图所示：

    image-20200414144109389

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

# git revert HEAD

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

image-20200414150640086

# git revert HEAD^

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

image-20200414151002143

# git revert HEAD^^

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

image-20200414180953703

# git revert HEAD~n

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

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

# 3.撤销revert操作

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

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

image-20200414153206034

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

image-20200414153456451

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

git revert --no-edit 582d127
1

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

image-20200414153724455

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

# Ⅲ.git checkout

# 1.git checkout commit_id

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

git checkout cb214
1

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

image-20200311111540863

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

image-20200311111719389

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

image-20200412001646768

image-20200311112656834

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

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

image-20200311113237150

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

image-20200311113209483

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

image-20200311113625297

此时的状态为：

image-20200412002213790

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

image-20200311114055018

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

image-20200412002655921

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

git branch mycommit  c4d5cc3
1

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

image-20200311115117279

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

image-20200412004042471

总结：

  • 通过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
1
2
3

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

# 二、git stash

# 1.git stash的作用

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

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

image-20200412235844426

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

image-20200413001632846

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

image-20200413001752227

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

image-20200413001917190

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

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

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

image-20200413002115302

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

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

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

image-20200413002256321

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

  • 其实，上面通过git stash将dev分支上工作区或暂存区中的修改，提交到了stash区域进行保存，并将dev分支回退到修改前的状态。如下图所示：

    image-20200413003349365

  • 切换到master分支时test分支上的修改依旧会被覆盖。所以，再次回到dev分支时需要从stash区域中恢复切换分支前保存的修改；

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

git stash list
1

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

image-20200413224408623

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

git stash save '注释'
1

image-20200413225024618

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

# 2.恢复stash存储的修改

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

# git stash pop

image-20200413225140030

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

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

image-20200413225221071

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

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

image-20200413225457480

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

image-20200413231349820

  • 如上图所示，在test分支上，进行第一次修改后，通过git stash将该修改作为修改0保存到stash中，此时分支中的文件并没有发生改变；

  • 进行第二次修改后，通过git stash将修改作为修改1保存到stash中，分支中的文件依旧没有发生改变；此时的stash中相当于保存着同一分支上两个修改后的版本；

  • 此时通过**git stash pop取出修改0，与test分支进行合并；再通过git stash pop**取出修改1，再次与test分支进行合并，两个版本合并自然会产生冲突。

手动解决冲突后，要进行一次提交才算完成了手动合并；随后查看stash：

image-20200413230750201

修改0仍然存在，说明**git stash apply**的作用为取出stash中最新（前面）的修改并与分支进行合并。但是，stash中存储的该修改并不会被删除；

# git stash apply stash@{n}

这是最常用的方法，作用为从stash中恢复特定的修改，并且不删除stash中的该修改。

将test.txt的两次修改通过git stash存储到stash中，如下图所示：

image-20200413232024080

通过**git stash apply stash@{1}**恢复stash中存储的修改1：

image-20200413232309330

如上图所示，成功地恢复了stash中的修改1，并且stash中的修改1并没有被删除；

总结：

  • git stash pop：恢复并删除stash中存储的最新修改；
  • git stash apply：恢复但不删除stash中存储的最新修改；
  • git stash apply stash@{0}：恢复但不删除stash中存储的特定提交；
最后更新于: 2020年6月13日星期六晚上7点32分

← 第五讲：远程仓库Github与Git图形化界面 →