git 找回丢失的commit

最新推荐文章于 2024-02-26 18:27:46 发布

转载最新推荐文章于 2024-02-26 18:27:46 发布 · 7.8k 阅读

android 专栏收录该内容

79 篇文章

订阅专栏

本文详细记录了一次在使用Git进行版本控制时的错误操作，导致丢失重要commit的过程，以及如何利用Git的复原功能成功找回commit的方法。反思指出谨慎使用reset hard命令的重要性，并提供了正确使用的替代方案。

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

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

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

Java代码  

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