git引发的血案（cherry-pick找回丢失的commit）

git 的错误操作，导致丢失了重要的commit，真是痛不欲生；
最后通过git神器终于找回了丢失的commit，但是需要总结和反思的地方有一些，同时需要加深git的学习，特献上本文以供参考

执行git reset --hard HEAD~1 ，删除了commit3，但是发现reset错了，晕菜了……
还好有后悔药（感叹git的强大啊，神马意外情况都考虑到了）满血恢复commit3,执行如下步骤：

git reflog
502dd0f HEAD@{0}: HEAD~1: updating HEAD
147b3b5 HEAD@{1}: commit: test3
502dd0f HEAD@{2}: commit: test2
0692c03 HEAD@{3}: commit (initial): test1

git reset --hard 502dd0f
git cherry-pick 147b3b5

丢失的commit3终于回来啦~~~~
虽然有利器，但是需要总结和反思的是，慎用reset hard啊，实在不行reset merge也是不错的选择。

===================================================

通过这次错误的使用reset，反思需要加强对reset的了解，不能再盲目的使用了

git reset [--hard|soft|mixed|merge|keep] [<commit>或HEAD]
作用：将当前分支reset到指定的<commit>或者HEAD(默认为最新的一次提交，即重设到最新一次提交之前的版本)

备注：
index，执行git add的操作，会对文件创建索引，所有被跟踪的文件索引会放入index，表示文件被修改待提交
working tree，当前工作区，被修改但未被add的文件，存储在工作区
ORIG_HEAD,用于指向前一个操作状态,每次的commit或者pull或者reset，git 都会把老的HEAD拷贝到.git/ORIG_HEAD，通过对ORIG_HEAD的引用可 以指向前一次的操作状态

1、hard(慎用)
重设index和working tree,所有改变都会被丢弃，包括文件的修改、新增、删除等操作，并把HEAD指向<commit>，
因此通过git log查看版本提交记录，被reset的版本记录会被丢弃，但可以通过git reflog查看

2、soft
不重设index和working tree,仅仅将HEAD指向<commit>,表示已经commit的文件会取消commit,
通过git status查看，文件会处于待commit状态“Changes to be committed”

3、mixed(默认)
重设index,但不重设working tree,表示已经被add的文件，被取消add，
通过git status查看，文件会处于待添加索引状态 “Changes not staged for commit”

4、merge
重设index，重设working tree中发生变化的文件，但是保留index和working tree不一致的文件

5、keep
重设index，重设working tree中发生变化的文件