通过git cherry-pick找回丢失的commit

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

执行git reset --hard HEAD~1 ,删除了commit3,但是发现reset错了,晕菜了…… 
还好有后悔药(感叹git的强大啊,神马意外情况都考虑到了)满血恢复commit3,执行如下步骤: 
Java代码   收藏代码
  1. git reflog  
  2. 502dd0f HEAD@{0}: HEAD~1: updating HEAD  
  3. 147b3b5 HEAD@{1}: commit: test3  
  4. 502dd0f HEAD@{2}: commit: test2  
  5. 0692c03 HEAD@{3}: commit (initial): test1  
  6.   
  7. git reset --hard 502dd0f  
  8. 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中发生变化的文件
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值