Git回滚代码之reset 和revert

上篇文章讲过了Git合并分支，这里不多做讲述，在开发中，有可能遇到的情况是可能有个bug在上个节点已经提交过了，这个版本有复现，现在需要再次测试上个节点的代码，怎么办？

那么我们今天研究一下git reset 和git revert的区别和联系。
先看下git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
git reset [<mode>][<commit>]
目的是重置当前分支的head指向到commit，并根据model更新索引(将其重置为<commit>)，如果省略model,则默认model是--mixed。model必须是下边的列表：

--soft

不用修改索引文件和工作树(和所有模式一样，将head指向commit)，这和git status一样，将保存所有要提交的更改。

--mixed

重置索引，但不重置工作树（即保留更改的文件，但不标记为提交），并报告未更新的内容。这是默认操作。(需要重新添加git add)

如果指定了-n，则删除的路径将标记为有意添加

--hard

重置索引树和工作树。自<commit>之后，对工作树中跟踪文件的任何更改都将被丢弃。

--merge

重置索引并更新工作树中<commit>和head之间不同的文件，但保留索引和工作树之间不同的文件（即具有未添加的更改）。如果在<commit>和索引之间不同的文件有未分页的更改，重置将中止。

换句话说，--merge执行类似于git read tree-u-m<commit>的操作，但会转发未合并的索引项。

--keep

重置索引项并更新工作树中<commit>和head之间不同的文件。如果<commit>和head之间不同的文件发生了本地更改，重置将中止。

If you want to undo a commit other than the latest on a branch,is your friend.
如果你不想取消当前分支的最近的commit，请看一下git revert 。这下边会讲。

我们造一个demo如下：

demo

现在我们的HEAD指向节点d248cd，但是我们想看节点的file_2的代码，
我们执行命令

git reset --soft head^1

Yong:test_git_revert Yong$ git log --graph
* commit b53ccde9dce1691b555dd5e42c8eb346f736ef81 (HEAD -> master)
| Author: fanguangyong <fanguangyong@xqafu.com>
| Date:   Fri May 10 14:29:07 2019 +0800
|
|     add file_2
|
* commit f5f2498c24c2771f906c2a1ac02b540f092fdcbb
| Author: fanguangyong <fanguangyong@xqafu.com>
| Date:   Fri May 10 14:28:55 2019 +0800
|
|     add file_1
|
* commit e002e347a24ad3079b283156887a7e7d67f881cc
  Author: fanguangyong <fanguangyong@xqafu.com>
  Date:   Fri May 10 14:28:05 2019 +0800

      Initial Commit

然后add file_3不见了,

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   test_git_revert/ViewController.m

可以看出来 代码回退过来了，刚才提交的记录也没了，只是将head指针前移动了一个，但是修改的test_git_revert/ViewController.m文件是更改了，想要执行代码，还是所有的代码，紧紧是记录回退了，代码却是所有的代码(代码未动),只是工作区的 跟踪状态不一样。

记录

如何测试完了在次更新到最新的节点呢？

Yong:test_git_revert Yong$ git commit -am 'add file_3_repeat'
[master 200cb3f] add file_3_repeat
 1 file changed, 1 deletion(-)
Yong:test_git_revert Yong$ git log --graph
* commit 200cb3fddf04c03cb1661bf7dc9e7f84525c28b3 (HEAD -> master)
| Author: fanguangyong <fanguangyong@xqafu.com>
| Date:   Fri May 10 17:01:15 2019 +0800
|
|     add file_3_repeat
|
* commit b53ccde9dce1691b555dd5e42c8eb346f736ef81
| Author: fanguangyong <fanguangyong@xqafu.com>
| Date:   Fri May 10 14:29:07 2019 +0800
|
|     add file_2
|
* commit f5f2498c24c2771f906c2a1ac02b540f092fdcbb
| Author: fanguangyong <fanguangyong@xqafu.com>
| Date:   Fri May 10 14:28:55 2019 +0800
|
|     add file_1
|
* commit e002e347a24ad3079b283156887a7e7d67f881cc
  Author: fanguangyong <fanguangyong@xqafu.com>
  Date:   Fri May 10 14:28:05 2019 +0800

      Initial Commit

刚才add file_3已经消失了，因为又提交了一次，message变成了add file_3_repeat，新增了一条提交记录。

那么我们修改一下文件,当前status是：

status
然后执行回滚

git reset --soft head^1

结果是：

--soft
则没有提交缓存去的文件没有丢失，回滚的代码的状态是追踪，但是没添加到缓存区。
测试完成当前版本的时候，则再次git add
git add

--mixed

Yong:test_git_revert Yong$ git reset --mixed head^1
Unstaged changes after reset:
M   test_git_revert/ViewController.m

Yong:test_git_revert Yong$ git log --graph
* commit b53ccde9dce1691b555dd5e42c8eb346f736ef81 (HEAD -> master)
| Author: fanguangyong <fanguangyong@xqafu.com>
| Date:   Fri May 10 14:29:07 2019 +0800
|
|     add file_2
|
* commit f5f2498c24c2771f906c2a1ac02b540f092fdcbb
| Author: fanguangyong <fanguangyong@xqafu.com>
| Date:   Fri May 10 14:28:55 2019 +0800
|
|     add file_1
|

代码混滚了，直接输出了最后的一次更改。提交的记录也丢失。
修改好代码 执行 git add。

git add

--hard

hard

执行之后查看本地git缓存区的数据有变化吗？

数据

--hard丢失节点3的数据。

如何恢复--hard丢失的节点数据

再测试一下本地有未追踪的文件的时候：

未追踪file
然后回滚代码：
回滚代码
文件丢失了怎么找回呢？那么我们测试一下git reflog看看能不能找回?
能不能找回
现在我们的head指向2b8edf8，那么我们让head指向到e55c3e4

$ git reset --hard head@{1}
HEAD is now at e55c3e4 add file3

未提交的丢失

我们执行查找lost的命令：

git fsck --lost-found


Checking object directories: 100% (256/256), done.
dangling commit e55c3e450d0a743b6a64db248065b3fdece153d1
dangling blob 6c3bfcdf65a27027ca3168bf2981487fa4ad5dfa

e55c3e450d0a743b6a64db248065b3fdece153d1是我们最后提交的代码节点，
6c3bfcdf65a27027ca3168bf2981487fa4ad5dfa是我们最后add之后形成的commit
然后执行git show 6c3bfcdf65a27027ca3168bf2981487fa4ad5dfa

git show
如果该条记录数 是dangling commit id类型直接使用git merge commit_id即可实现数据恢复，如果是dangling blob id类型则需要使用git show 6c3bfcd> somefileName将其转储到文件或者使用使用脚本下载本数据写入到相关的文件
最后修改的文件成功找回。

那么不会回退节点怎么处理呢？
git给我们提供了git revert，会形成一个新的节点。

名称
git-revert- 恢复一些现有的提交

描述
给定一个或多个现有提交，还原相关修补程序引入的更改，并记录一些记录它们的新提交。这需要您的工作树是干净的（没有HEAD提交的修改）。

注意：git revert用于记录一些新的提交以反转某些早期提交的效果（通常只有一个错误的提交）。如果你想丢弃工作目录中所有未提交的更改，你应该看到git-reset [1]，特别是--hard选项。如果你想在另一个提交中提取特定文件，你应该看到git-checkout [1]，特别是git checkout <commit> -- <filename>语法。请注意这些替代方案，因为它们都会丢弃工作目录中未提交的更改。

--continue
使用.git / sequencer中的信息继续正在进行的操作 。可以在解决失败的挑选或恢复中的冲突后继续使用。

-- quit
忘记当前正在进行的操作。在樱桃挑选或恢复失败后，可用于清除顺序器状态。

--abort
取消操作并返回到预序列状态。

例子
git revert HEAD~3
还原HEAD中第四个最后一次提交所指定的更改，并使用还原的更改创建一个新提交。

git revert -n master~5..master~2

将提交所做的更改从master（包含）中的第五次提交恢复为master（包含）中的第三次提交，但不要使用还原的更改创建任何提交。恢复仅修改工作树和索引。

恢复一个提交记录并生成一个新的记录：

新的记录
恢复并生成一个新的记录

生成了这个，又不想要了这个节点怎么办？
执行git reset --hard head^1即可

hard

总结来讲：

--hard恢复容易丢文件，切不容易查找，慎用。回滚代码并生成新的提交记录可使用git revert，用完之后再使用--hard丢掉即可。使用reset的时候最好有为缓存的文件及时add和commit，这也是个好习惯。

参考资料：
官方资料
falstaff