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] [或HEAD]
作用：将当前分支reset到指定的或者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指向，
因此通过git log查看版本提交记录，被reset的版本记录会被丢弃，但可以通过git reflog查看

2、soft
不重设index和working tree,仅仅将HEAD指向,表示已经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中发生变化的文件