git 找回丢失的commit

From : http://dmouse.iteye.com/blog/1797267

 

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中发生变化的文件