git revert 与 git reset

Git版本回滚之 git revert 与 git reset

在使用 git 的时候，如果错误push之后，经常会回滚版本。

git的回滚有两种方式：

revert 和 reset 看上去达到的效果是一样的，但其实是完全不同的过程。

如果已经 push 到线上代码库， reset 删除指定 commit 以后，再 git push 可能导致一大堆的冲突。但是 revert 并不会。
如果在日后现有分支和历史分支需要合并的时候，reset 恢复部分的代码依然会出现在历史分支里。但是 revert 反向提交的commit 并不会出现在历史分支里。
reset 是在正常的 commit 历史中，删除了指定的 commit，这时 HEAD 是向后移动了，而 revert 是在正常的 commit 历史中再 commit 一次，只不过是反向提交，他的 HEAD 是一直向前的。

从上面这张图，可以直观的了解 git 的工作流程。

最初的状态是我们正在书写代码，这个状态对应图中的 Working diretory。这个时刻，我们的代码是独立的，跟 git 没有一点关系。
随后，我们把当前编辑的 A 文件 add 到 git 中，这个时候就跟 git 发生了关系，git 接收了我们的代码。然后把这个文件存入了自己的暂存区 stage ，后面我们对这个文件的任何更改，git 都会知晓。这个状态对应图中的 Stage/Index。
我们把写好的 A 文件 commit 到 git ，这就有了一次提交历史，对应图中的 History。在 git 中只要 commit 过的文件，都有各种方式可以恢复，基本来说，就是不会丢了。

随着项目的进行，我们发现代码写的不好，需要回退到上一次的提交，我们有几个命令可以选择。

常见以下三个命令：

这个命令非常危险，是 git 中少有的几个会丢失信息的操作。它会把回退点之前的所有信息都删掉，一个不留，干干净净。
举个例子：
现在我把 A 文件修改了两次，到了 C 状态，并且已提交。
那么我的分支指针是指向 C , 当前文件编辑的状态也是在 C

   (F)

A-B-C

    ↑

  master

我输入了git reset --hard，结果会变成：

 (F)

A-B

  ↑

master

对的， C 状态彻底没有，再也找不回来。所以，没事不要用这个命令。

同样是这个状态：

   (F)

A-B-C

    ↑

  master

我输入了git reset --soft，结果是：

 (F)

A-B-C

  ↑

master

文件状态与分支的指针都指向上一个提交，C 还是在的，只是没显示。

仍然是这个场景：

   (F)

A-B-C

    ↑

  master

我输入了 git reset --mixed，结果是：

   (F)

A-B-C

  ↑

master

分支指针指向上次提交点，但是文件状态还是在当前文件 C ,我看到的现象就是 C 文件还在，但是没有 add ，是红色的。

可以看出，三个命令中 mixed 是最好的回退处理方式，其实这也是 git reset 的默认参数。