Git reflog 是本地仓库的“操作时间线”，记录所有 HEAD 移动历史，可找回被 git reset --hard 丢弃的提交；默认保留 90 天，通过 git reflog 查看，用 HEAD@{n} 定位并恢复。
Git reflog 是你本地仓库的“操作时间线”，它记录了所有 HEAD 的移动历史，包括那些被 git reset --hard 丢掉的提交。只要没执行过 git gc（且未过期），这些提交就还在磁盘上，完全可找回。
理解 reflog 的本质和生命周期
reflog 不是分支，也不参与远程推送，它是 Git 为每个引用（尤其是 HEAD）自动维护的操作日志，保存在 .git/logs/HEAD 中。默认保留 90 天（或 30 天，取决于配置），期间即使提交从分支上“消失”，也能通过 reflog 定位。
- 运行
git reflog或git log -g查看完整操作记录 - 每行格式类似：
abc1234 HEAD@{0}: reset: moving to HEAD~2，其中HEAD@{n}就是可回溯的快照点 -
HEAD@{0}是当前状态，HEAD@{1}是上一次 HEAD 所指，以此类推
定位被 hard reset 覆盖掉的提交
执行 git reflog 后，快速扫描带有 reset、commit 或 checkout 关键字的行。重点关注 reset 操作前的那一行——它大概率就是你丢失的提交。
GitCode API Usage
下载
简单易用的 GitCode API SKILL，提供 CLI 和轻量级 Python SDK 两种调用方式，用于与 GitCode 的 REST API 进行交互。支持加密访问令牌、异步调用以及完善的类型提示。 - 文档：https://gitcode-api.readthedocs.io/ - PyPI 页面：https://pypi.org/project/gitcode-api - GitHub 仓库：https://github.com/Trenza1ore/GitCode-API
- 例如：你执行了
git reset --hard HEAD~3，那么HEAD@{3}很可能就是 reset 前的 HEAD 提交 - 用
git show HEAD@{3}预览内容，确认是否包含你要恢复的代码 - 若不确定编号，可用
git reflog --date=iso加时间辅助判断
安全恢复提交的三种常用方式
根据你想恢复的程度选择策略，避免二次覆盖：
-
只恢复提交对象（推荐）：运行
git cherry-pick HEAD@{n}，把该提交重新应用到当前分支顶部 -
重置整个分支到该点：运行
git reset --hard HEAD@{n}（慎用，会再次改写 HEAD，但这次是往回走） -
新建分支便于检查：运行
git branch recover-branch HEAD@{n}，再git checkout recover-branch安全检出对比
预防下次误操作的小习惯
reflog 是兜底手段，不是工作流。日常可加几条轻量防护：
- 执行
git reset --hard前，先记下当前git rev-parse HEAD或运行git reflog -n 3看一眼最近状态 - 对重要分支，重置前加个临时标签：
git tag backup-before-reset - 把
git config --global gc.reflogExpire 365.days设长一点，延长 reflog 保留时间
