问题描述
代码回滚这个操作，在实际工作中用的不是太多（前提是规范使用git进行多人协作开发）。一般都是出问题的时候，才会回滚到之前的代码。比如：刚发布的版本到生产环境服务器以后，出现了一个很奇怪的bug，而在测试环境服务器，却没有这个bug（开发和测试都一脸懵逼）。为了不影响用户的使用，所以得赶紧回滚到之前的代码版本。
本文记录一下具体回滚操作思路和步骤
回滚思路
- 每一次提交
git push后都会在git仓库中生成一个哈希值，这个哈希值就是每一次提交的身份证 - 并且我们根据每次的
git commit -m '注释'可以看到之前的每次提交的版本 - 我们只需要
git checkout 哈希值就可以切换到之前的某个版本了 - 切换回滚回去以后，可以另开一个
临时分支，打个包发生产
场景案例
假设我有一个仓库，我进行了四次操作：
- 第一次操作，新建编辑了one.txt文件；
- 第二次操作，新建编辑了two.txt文件；
- 第三次操作，新建编辑了three.txt文件；
- 第四次操作，新建编辑了four.txt文件； 文件如下图：
git仓库提交图示：
git哈希值图示：
注意，不同公司的gitlab页面可能不一样，不过找一找都能找到每次提交的哈希值的，有了哈希值，就能找到之前的版本了，相当于有了身份证就可以找到确定的对应的人了啊
举例：公司的代码是four.txt提交以后出问题的。问了以防万一，我们要把代码回滚到two.txt时候，给用户使用。所以我们只需要执行git checkout 6208488 6208488是two.txt的哈希值(上图可看到)，就能时光穿梭回去two.txt的时候了。git图示：
注意哈希值其实很长的，不过我们只需要前7位数就可以了，不需要全部复制粘贴过来。当然，全复制也可以哇
git checkout 6208488图示：
文件夹目录图示：
注意，在当前历史穿梭哈希值的时候，是不能直接提交，直接git push的。直接git push会报错提示：
历史穿梭哈希值不能直接git push
有的道友说了，我就想git push，那怎办？其实也行。直接：git push -f 强制推送，但这样操作，就会把之前的three.txt和four.txt操作给覆盖掉了！于此同时，gitlab中也就没了three.txt和four.txt的文件了。当然如果确定three.txt和four.txt真的不要了，也可以强制推送，进行覆盖。具体情况，具体分析。
个人建议不要强制推送覆盖，方便排查问题。建议新切一个分支
建议新切一个临时分支进行打包发布生产使用图示：
关于git其实建议命令行和可视化工具以及gitlab搭配使用，这样效率或许会更高。好记性不如烂笔头，记录一下吧^_^
