假设我于 2020 年 1 月 1 日在 github.com 上创建了一个存储库,将其克隆到本地并在此状态下放弃了几天。
而且,在 1 月 7 日本地完成后,我想将日期更改为更早的日期 - 例如 1 月 2 日。很明显,在本地你可以随意更改系统时间,但问题不是关于 git,而是关于 github 服务器:是否有可能在 1 月 7 日提交时假装提交是在不同的日期进行的,还是无法隐藏技术痕迹?
这个问题对我来说具有以下实用价值:是否可以将 git 用作具有法律意义的时刻,即 如果 1 月 2 日的提交在 github 上可见,那么您可以显示或反驳在本地创建提交的日期以及推送到 github 服务器的日期。类似于离线方式“给自己寄几个信封和你的手稿,以便以后你可以通过邮戳证明你的作者身份”,只有在数字时代。
我对技术方面感兴趣,只要可能或不可能。我有一个关于 rebase 的想法,所以我有兴趣了解在哪里查看以及需要注意什么,以吸引诸如“本地提交创建时间”和“推送到 github 服务器的日期”等事实。
Github 界面显示的提交日期是在 git 中创建提交的日期,而不是推送到服务器的日期。它实际上可以是任何东西,具体取决于当地时间(甚至在上一次提交之前!)。也就是这里不存在“换货”的问题,这个日期的真实性并不能初步保证。
但是,如果提交日期与创建日期不同,有几种方法可以找出提交到服务器的日期:
1. 本地 - 使用 git reflog 命令:
当然,这些日期也可以更改,所以就证明而言,这并没有给出任何东西。
2. 如果存储库有配置了事件的 CI 任务
on: [push],那么在 CI 日志中,提交任务的启动将在它被发送到服务器时准确可见。例如,我在乌拉尔时间 10:08 在本地创建了这个提交- 这是 5:08 GMT,并在 11:53 GMT 将其发送到服务器。CI 日志第二次显示:https ://github.com/MSDN-WhiteKnight/CilTools/runs/1235315854CI 日志可以删除,但据我所知,不能伪造,至少在使用来自 Github Actions 的标准 VM 时是这样。
3、如果一个Pull请求关联了一个分支,在界面中使用push -f命令时,发送到服务器的实时时间是点亮的:
多亏了这一点,如果提交发生了更改/删除,则可以检测到这一点,因为在这种情况下总是会进行强制推送。但是,正如我所说,Pull 请求必须与分支相关联,并且必须在强制推送之前创建。
因此,有一些迹象可以让您检测到提交的错误时间,但它们都不是绝对的,几乎不可能具有法律意义。我认为只有你自己的 Github Enterprise 服务器才能完全解决问题——你可以在那里打开日志并查看所有内容。