m00 / \ m01 m00-1 / \ m02 m00-2 \ m00-3
但是，假设我们合并完了，创造合并错了，该怎么办呢？或者其余一个场景，我们在从m00-2存档到m00-3存档到游戏过程中，创造中途漏掉了某个蘑菇没有吃。我们想从m00-2存档重新进行游戏，把那个蘑菇给吃了，该怎么处理呢？一种办法是忽略。我们可以重新读取m00-2的存档，从此处重新开始一个新流程。
git checkout 5eab37973211a
进行游戏后，我们启动一个新流程，并保存。这里不再赘述，请参考从游戏存档聊聊Git版本管理。
git switch -c load-01git add player.***git commit -m 'm00-4'
此时的存档变成了这样：
m00 / \ m01 m00-1 / \ m02 m00-2 / \ m00-3 m00-4
不过这个m00-3看着挺烦人的。git供应了两种办法来进行回滚操作：
第一种办法是reset其余一种是revertreset我们一个个来演示 ，先看reset。直接实行如下命令：
git reset HEAD^ --hard
实行完成后，你就会创造存档又回到了合并前的样子了，然后你就可以连续玩游戏了。
m00 / \ m01 m00-1 / \ m02 m00-2
我们对上面的命令做一个大略的阐明：
HEAD可以理解为一个指针，它指向了当前分支（流程）中最新的一次提交（存档）后面的^表示向前退一步，即指向前一次提交（存档）。如果要退两步，那便是HEAD^^；退三步便是HEAD^^^；如果推10步呢？可以利用HEAD~10。—hard表示目录中的存档也须要变革。如果你不添加—hard，你会创造player.***文件的内容并没有变革。你还须要再实行一下git restore player.***还记得快速理解Git中提到的观点模型吗？事情区、索引区和本地/远程仓库。针对不同的区域，reset支持多种模式的重置，上面的—hard便是个中之一：
soft：将HEAD回滚到指定的commit处，对索引和事情区没有影响。紧张用于对末了一次提交的修正。比如：你commit了修正后创造这个commit里漏掉了一个文件，你可以再提交一次。也可以回滚这次提交，然后将漏掉的文件添加到索引后再次提交。mixed：默认reset操作。以目前HEAD所指向的commit为基准，重置索引区，不重置事情区。举个例子：假设你修正了a.***文件，并将其添加到索引区。如果此时实行reset，则添加索引区的操作被回滚，而a.***文件的修正还保留。hard：以目前HEAD所指向的commit为基准，重置索引区和事情区。举个例子：假设你修正了a.***文件，并将其添加到索引区。如果此时实行reset，则添加索引区的操作被回滚，同时a.***也被回滚到修正前的状态。revert除了利用reset，我们也可以利用revert来进行回滚操作。首先我们还是先规复到下面的存档构造（回顾一下我们是怎么操作的）：
m00 / \ m01 m00-1 / \ m02 m00-2 \ m00-3
规复完之后，player.***中的内容如下所示： ####....#. #..###.....##.... ###.......###### ........... ######### 1 - 3 ########## ...#..###.... ....##..... .... .... #### #### ###### ######
我们实行如下命令进行规复：
git revert HEAD
实行完之后，会涌现一个类似下面的提示
Revert "m00-3"This reverts commit d1b1ccaedaa919e45dcf77960b19948216d86ca9.# Please enter the commit message for your changes. Lines starting# with '#' will be ignored, and an empty message aborts the commit.## On branch load-00# Changes to be committed:# modified: player.***
你可以修正一下笔墨，也可以直接:wq退出。操作完成后，player.***中的内容规复为：
####....#. #..###.....##.... ###.......###### ........... ######### 1 - 1 ########## ...#..###.... ....##..... .... .... #### #### ###### ######两者的差异
如上所示，reset和revert都可以规复前一次的提交，那两者的差异是什么的？
对付reset来说，便是对指定的提交进行了撤回。当实行了reset后，全体存档就规复到了提交前的状态而revert并不是，它是打了一个patch，将前一次的提交进行了抵消。什么意思呢？我们实行一下git log就能比较清晰的看出差异了。commit 45c8dc8fecffc4935d38484100d1f6b548cc35ba (HEAD -> load-00)Author: 一瑜一琂Date: Fri Mar 18 22:49:38 2022 +0800 Revert "m00-3" This reverts commit d1b1ccaedaa919e45dcf77960b19948216d86ca9.commit d1b1ccaedaa919e45dcf77960b19948216d86ca9Author: 一瑜一琂Date: Fri Mar 18 22:26:40 2022 +0800 m00-3commit 5eab37973211a466cc692999b93c16561cc2a157Author: 一瑜一琂Date: Thu Mar 17 14:19:49 2022 +0800 m00-2commit 79bd5c56e020eeb47919be29b29928e7397c1929Author: 一瑜一琂Date: Wed Mar 16 15:46:39 2022 +0800 m00-1commit b0d5581b592f3d5faaca744e88eed604f2289904Author: 一瑜一琂Date: Wed Mar 16 14:05:19 2022 +0800 m00```
可以创造，我们多了一个存档，便是上面显示的Revert "m00-3"。这个提交便是m00-3的逆操作，它抵消了m00-3的修正。全体存档看起来像这样：
m00
/ \
m01 m00-1
/ \
m02 m00-2
\
m00-3
\
Revert "m00-3"
为什么须要revert呢？或者revert的利用场景是什么呢？假设你现在想抵消散落m00-1的记录，那么你就可以利用revert！
总结
此时如果你利用了reset，那么m00-2和m00-3这两个提交就都消逝了。本文大略梳理了Git回滚的办法。到目前为止，我们都只是在操作本地仓库，下面我们来聊一聊远程仓库。
