Git reflog记引用怎样移动，为什么不是另一份共享提交史

两位开发者拥有同一项目的提交资料，却不一定拥有相同的reflog。Git官方手册将它定义为本地仓库中分支端点和其他引用的更新记录；用户手册又明确指出，这种历史不共享，描述的是本地分支怎样随时间变化。[1][2] 所以，一份项目提交历史不能自动替另一位开发者补出本地引用移动的时间线。

这里先区分“提交”和“引用指向”。阅读提交资料，关注哪些对象及其历史关系；阅读reflog，关注某个引用先前指向哪里、后来何时变了。两种信息可以涉及同一个提交标识，却没有因此变成同一份记录。端点的位置变化是这篇文章要解释的对象，不是给提交父链换一种简短显示方法。

官方给出的HEAD@{2}例子，含义是HEAD在前两次移动之前的位置；master@{one.week.ago}则表示本地master一周前指向哪里。[1] 一个按移动次数定位，一个按过去时间定位，两者都需要保留所查询的引用名称。“两次移动”不能直接改写成“两个父提交”，因为原文正在计数的是引用值的更新，而不是描述提交图里走过几条父关系。

HEAD还有自己的记录。用户手册说明，HEAD一周前的位置，不等同于当前分支一周前的位置；git-reflog文档另外指出，HEAD的reflog会记录分支切换。[1][2] 因此，整理一段本地工作经过时，只写“一周前的版本”可能仍不明确：是在问当时检出了什么，还是在问某条指定分支当时指到哪里？引用对象不写清，时间相同也可能回答了另一个问题。

可以作一个没有真实仓库的资料例子：甲想说明自己此前查看过哪些分支，乙想说明某条分支的端点此前怎样改变。两人都在谈过去，却各自需要不同引用的记录。这个例子只用于辨认问题，不包含切换、重置或恢复命令，也没有声称取得任何人的本地日志。文档能解释记录的含义，实际记录是否存在仍需对应真实仓库。

reflog也不能当成永久备份。手册另列记录清理与过期机制，用户手册在相邻段落还提醒，某些情况下reflog并不能帮助找回变化。[1][2] 本篇不引用期限数字或提供清理、恢复步骤。其用途是帮助读者把本地引用移动与可协作共享的普通历史分开，而不是保证某份已失资料可以恢复。

本文采用git-reflog的DESCRIPTION及用户手册Reflogs节与邻接。所读前者页面标示最后更新对应2.51.1，后续至2.56.0无变化；这不是本机版本证明。用户手册的正式提取文本有长度截断，本文没有通读整本，只采用实际读到的上述部分，未执行任何仓库操作。