如何解决如何找到新的强制推送提交 ID 覆盖的预提交 ID? 长
我将代码更改添加到 repo,我可以通过 git log -n1
看到提交 ID。
然后,我使用 git add -u; git commit --amend; git push -f
将新更改组合到预提交 ID。
然后我突然忘记了第二次更改的差异是什么。但是预提交 ID 在 git log
历史记录中消失了。
如何找到丢失的提交?
解决方法
TL;DR:使用引用日志。
长
git commit --amend
操作具有“将旧提交推到一边”的效果。如果我们绘制提交,根据分支名称找到,我们会得到这样的图片:
... <-F <-G <-H <--branch
这里的每个大写字母代表一个 Git 提交哈希 ID。 分支名称,在本例中为 branch
,包含 最新 提交 H
的哈希 ID,因此:
git rev-parse branch
打印出这个哈希 ID。 Git 能够使用这个存储的哈希 ID 从提交数据库中读取提交 H
。
提交 H
本身在其元数据中存储较早提交 G
的原始哈希 ID。因此,从数据库中读取 H
后,Git 可以找出这个哈希 ID,并使用它从数据库中检索提交 G
。
检索到 G
后,Git 拥有来自 G
的元数据,它给出了较早提交 F
的哈希 ID,因此 Git 可以从数据库中检索提交 F
。这当然有元数据,包括另一个更早提交的哈希 ID,等等。
当我们以正常方式添加一个 new 提交时,Git 所做的是:
- 为新提交写出一个新快照(我们将这个新提交称为
I
,使用字母表的下一个字母)。 - 写出提交
I
的元数据:我们的姓名、我们的电子邮件地址、当前日期和时间等。在此元数据中,Git 包含 当前 提交H
的哈希 ID,作为提交I
的父项。 - 使用
git commit-tree
的内部版本将所有这些作为新提交写入对象数据库。写入提交的行为会产生新的哈希 ID:我们将称之为I
。 - 将提交
I
的哈希 ID 存储在当前分支名称中。
第 4 步使 branch
指向新提交 I
,而不是现有提交 H
。当我们绘制结果时,我们有:
... <-F <-G <-H <-I <--branch
正如您所看到的,从最后开始向后工作的过程现在将找到提交 I
,然后提交 H
,然后提交 G
,依此类推。
git commit --amend
的作用是绕过当前提交,让新提交 I
直接指向 parent(s ) 当前提交。在这种情况下,由于 H
指向 G
,Git 会使新提交 I
直接指向 G
:
H
/
... <-F <-G <-I <--branch
Commit H
确实 仍然存在,反正有一段时间了。但是无处可找到它的哈希 ID。如果它仍然在你的屏幕上,或者在一个窗口的回滚中,你可以这样抓取它:Git 需要哈希 ID;分支名称只是提供哈希 ID 的一种方式。如果您可以剪切并粘贴哈希 ID,那就没问题了。
但这就是上面reflog这个词的含义。每当 Git 替换存储在分支名称或特殊名称 HEAD
中的值时,Git 将之前的值保存在日志中。 此日志是可选的,但对于您的存储库,它默认为“开启”(至少如果您使用传统的 Git;如果您使用的是 Eclipse 或 JGit 或其他一些仅使用相同的数据库格式)。因此,当 git commit
和 git commit --amend
覆盖存储在分支名称中的哈希 ID 时,它们会在日志中保存上一个哈希 ID。
不带参数运行 git reflog
将转储 HEAD
的引用日志。这是最活跃的 reflog,里面有最多的“东西”,所以它有更多的信息需要筛选。
运行 git reflog branch
,如果您在名为 branch
的分支上,会转储 branch
的引用日志。 (如果您使用的是 main
或 master
,请使用 git reflog main
或 git reflog master
。)这将显示该分支名称的更新。
在这两种情况下,您都可以在 git commit --amend
之前找到提交的哈希 ID。这将是被推开的提交的哈希 ID。所以你现在可以运行:
git diff <hash> HEAD
例如比较两次提交。
还有其他使用引用日志的方法。请参阅 documentation for git reflog
和 the documentation for writing revision ID expressions。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。