Git Reset 深度解析-优快云博客

本文链接：https://blog.youkuaiyun.com/wangyuanyuanIt/article/details/83063502

本文详细介绍了如何使用git reset找回Commit，包括git reset的硬重置、软重置和混合重置的区别，以及如何利用reflog和cherry-pick找回丢失的提交。此外，还讨论了git记录的保存问题，包括git gc的配置和提交的生命周期。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一. 找回Commit###

通过以下例子来了解下具体怎么回滚：

$ git init
$ touch foo.txt
$ echo 'test data' >> foo.txt
$ git add foo.txt
$ git commit -m "initial commit"

$ echo 'new data' >> foo.txt
$ git commit -a -m "more stuff added to foo"

你现在看git的历史记录，你可以看到两次提交：

$ git log
* 98abc5a (HEAD, master) more stuff added to foo
* b7057a9 initial commit

现在让我们来重置回第一次提交的状态：

$ git reset --hard b7057a9
$ git log
* b7057a9 (HEAD, master) initial commit

这看起来我们是丢掉了我们第二次的提交，本地的修改也消失了，没有办法找回来了。但是 reflog 就是用来解决这个问题的。简单的说，它会记录所有HEAD的历史，也就是说当你做 reset，checkout等操作的时候，这些操作会被记录在reflog中。

$ git reflog
b7057a9 HEAD@{0}: reset: moving to b7057a9
98abc5a HEAD@{1}: commit: more stuff added to foo
b7057a9 HEAD@{2}: commit (initial): initial commit

所以，我们要找回我们第二commit，只需要做如下操作：

$ git reset --hard 98abc5a

再来看一下 git 记录：

$ git log
* 98abc5a (HEAD, master) more stuff added to foo
* b7057a9 initial commit

同时本地对foo.txt做的修改也回复回来了。

这里在提一下另一个找回Commit的操作git cherry-pick 98abc5a,这个操作与上面的reset操作区别在于后者只是单纯的提取98abc5a这个Commit进行回滚，如果在b7057a9和98abc5a之间还有其他的Commit操作，则会忽略中间的这些Commit做的修改，所以应用这个命令有可能会文件的冲突。

二. git 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”