Git回滚的常用手法?我修改了a.txt和my_dir/b.txt，并将将他们加入了index区域，当前运行git status得到如下
Git回滚的常用手法
?我修改了a.txt和my_dir/b.txt，并将将他们加入了index区域，当前运行git status得到如下输出
?这里再执行git reset . 将当前目录及子目录内的所有修改移出index区域，再次运行git status命令
?到这一步之后，就用上面提到git checkout就可以解决问题了。
?
commit之后的回滚
这种情形是git本地回滚里面最复杂，也是最容易让人迷糊的了，因为针对不同的情况，方法比较多，所以不是很好记。
修改最后一次commit的记录：很多时候先要回滚仅仅是因为自己对最后一次的commit的漏掉（注意，这里说的漏掉不仅仅是你少提交了文件的修改，也包括你多提交了一下你不想要提交的东西）了一些东西，想要回滚这次commit之后再重新commit。如果是这样的话，没有必要真的非要先回滚再重新commit。只要在在自己已经满意了自己所有的修改之后，直接执行git commit --amend，就可以开启上次提交的“补救”提交模式，然后把你对上次所有漏掉的东西加上去就好了。下面看个例子：我进行了一次错误的提交，修改的内容如下：
?目前commit 记录如下：
?现在我想补救这次commit，相当于取消这次新加入的文件b.txt、取消对a.txt第三行的修改，然后加入我真正想要的修改：在my_dir下增加一个c.txt，并且修改a.txt的第三行为另外一句话。
?
?再次通过git log查看commit记录
?请注意比较最新的一次commit的修改，其实已经被修改为另一个SHA1的值了。这里请注意，从某种意义上说（实际上这种替换在reflog中很容易追踪到痕迹，只是在所有的commit逆向引用链条中，我们已经找不到之前的那个fad4...），这种操作已经做到了无痕修改最后一次提交。这和SVN的逆向merge是本质不同的。回滚中间的某次提交（当然也包括最后一次）：比如我想要回滚上图中倒数第二次提交，就是HEAD^那次，我们先通过git show HEAD^看看那次提交都干了啥？
?然后再通过git revert HEAD^ 来回滚这次操作，然后我们得到了下面的提示：
?杯具，冲突了。。。其实，只要你熟悉任何一种VCS工具，想想这个场景，其实也是挺正常的。那就git status看看哪些个文件冲突了吧。
?其实你只要仔细看看上面的说明信息，应该已经知道该怎么解决这个冲突了。明显，a.txt是冲突发生的文件：
?打开这个文件，可以看到标准的冲突标识文件。这里正是之前我们采用补救式提交方式修改的那句话。至于冲突怎么解决很容易，看你究竟想要啥了，自己去编辑，去掉冲突范围标识符号，保存文件即可。然后按照git正常的流程再次提交，编辑提交的信息即可。再次提交之后的log信息如下：
?上面我们基本上演示了一个标准的revert场景（包括了冲突解决），从这个过程可以看出，git revert和SVN的逆向merge几乎如出一辙，就是将你需要回滚的那次commit所做的所有操作，反向操作一次，然后重新做一一个单独的commit对象进行提交。这个过程是否发生冲突，就取决于你的修改了。请注意，这个过程你虽然回滚了你不想要的修改内容，但是你没法抹掉那次commit在history中的信息，请注意上图的第三行，他依旧坚挺的躺在那里。这个也是git revert的特点。当然，git revert实际上也提供-n（--no-commit）参数，用来表示仅将revert的修改体现在当前的working tree，不自动进行提交。但是如果你真的想回滚那些修改的话，再次commit这个环节是逃不掉的。回滚最后的N次提交（永远从commit的history中抹掉这些记录）：这种场景就轮到git reset登场了。git reset的帮助文档写的非常清楚，在回滚commit的场景中，他的作用就是将当前的HEAD reset到你指定的那个分支。但这个过程中最值得注意的就是你使用的参数，最常用的主要是--soft（个人推荐使用这个，他不会修改你目前index或者working tree中所做的任何修改）/--mixed（你在reset时不加任何参数时的默认行为，会默默把你在index中的修改给灭了！）/--hard（这个是我绝的最危险的参数，会把你index和working tree中的所有修改毁灭的毛都不剩，使用之前请三思，这确实是你要的行为！）这三种。因为我推荐使用--soft参数，下面主要演示回滚到3f412...那次的记录（git reset --soft HEAD~2）：
?从上面可以看出来，你的index区域忽然多了很多未提交的修改，这些就是回滚回来的记录，要怎么处理他们，就看你的了。这时我再来看看log的记录信息：
?最新的提交已经变成我们希望的那次了。其实从git reset的解释中，我们就可以看出，git reset是一个“斩断”式的回滚操作，因为你把当前的HEAD指针直接移动到了你需要回滚到的那次记录。而git本身的commit链条是逆向回溯的，所以你在提交历史里面再也找不到当前HEAD指向的commit之后的记录了。（不过如果你是git文艺青年的话，你当然知道，想找到那些表面上找不到的commit，通过reflog也是易如反掌）。
好了，到这里，常用的git回滚操作和场景都介绍完了。希望对不熟悉git的TX能有所帮助。
