Timestamp automatici per i commit Git con una GitHub App

2026-09-19 timestamp git blockchain proof

使用 GitHub App 自动为 Git 提交添加时间戳

你已经知道，证明提交存在的时间可能与代码本身同样重要。如果专利流氓、客户纠纷或前合作者质疑你的时间线，自托管的 Git 日志通常是不够的。内部日志可以被编辑，托管仓库的历史记录也不是不可篡改的现有技术证明。

困难的方式是学习底层时间戳协议，为每次提交手动运行命令、复制哈希、等待确认，并将回执存储在安全的地方。当你拥有多个仓库、多个开发者或一个繁忙的发布周时，这种方法就会崩溃。

Timestamp GIT 消除了所有这些手动负担。你只需安装一次 GitHub App，选择要保护的仓库，之后每个新提交都会在每晚的计划任务中自动时间戳到比特币区块链中。无需运行 CLI 工具，无需手动管理回执文件，也无需学习 OpenTimestamps 命令。

如果你还不了解这背后的原因，请参阅什么是密码学现有技术，为什么它对软件很重要？。

本文介绍自动化路径：一次性设置、从提交到比特币锚定之间发生什么、如何监控你的证明，以及如何长期保持流程健康。

一次性设置：安装 GitHub App

整个设置就是一次 GitHub App 安装。没有本地代理、没有配置文件、没有需要维护的脚本。

步骤如下：

从 GitHub Marketplace 安装 Timestamp GIT GitHub App。
选择你要监控的仓库。
- 公共仓库在免费层中受支持。
- 私有仓库需要 Pro 或 Enterprise 计划。
选择你的部署模式：
- 标准模式：GitHub App 从源仓库读取 HEAD 提交哈希，并将证明文件写入目标仓库或分支。
- 企业 ZK 模式：在你的环境中运行的 GitHub Action 仅将提交哈希推送到 Timestamp GIT API。Timestamp GIT 对源仓库零读取权限。
确认访问权限。
- 标准模式需要对源仓库的读取权限和对目标仓库的读写权限。这是 GitHub 权限系统的要求：不存在仅提交哈希的读取权限。
- 企业 ZK 模式只需要对目标仓库的读写权限。源仓库永远不需要向 Timestamp GIT 授予读取权限。
完成。从此刻起，新提交会被自动获取。

安装后，你可以从 Timestamp GIT 仪表板管理被监控的仓库。无需编译、无需运行守护进程、无需配置 cron 任务。

自动化流水线：从提交到比特币锚定

一旦安装了 GitHub App，整个过程就会在你无需思考的情况下运行。

每次提交后发生什么

当你向被监控的仓库推送提交时，GitHub App 通过 webhook 检测到新提交。该应用不会读取你的源文件。它只提取提交哈希——这是该时刻仓库状态的密码学安全指纹。

该提交哈希被放入队列，等待下一个夜间批次。

夜间锚定运行

每晚，一个工作进程运行以下流水线：

收集每个被监控仓库的所有排队提交哈希。
为当天创建清单文件。
从收集的哈希构建 Merkle 树。
使用 OpenTimestamps 协议将 Merkle 根锚定到比特币区块链中。
生成证明回执并推送回专用的时间戳分支或影子仓库。

比特币确认本身通常需要几个小时。这意味着证明文件通常在夜间运行后几个小时出现在你的仓库中，而不是在提交后立即出现。

证明交付

交付物是一个 .ots 回执文件加上每日清单。这些文件被写入专用分支或影子仓库，与你的正常源历史分开。

你可以使用普通的 Git 命令检查结果：

# 夜间锚定完成后
git fetch origin

# 查找专用的时间戳分支或影子仓库
git branch -r

# 检出包含 .ots 回执的分支
git checkout <timestamps-branch>

# 列出每日证明文件
ls -1 *.ots

确切的分支名称取决于你的仓库配置。

企业 ZK 模式

对于无法向第三方授予任何源代码访问权限的团队，企业 ZK 模式改变了数据流。

GitHub App 不再读取源仓库元数据，而是在你的基础设施内部运行一个小型 GitHub Action。该 action 仅将提交哈希推送到 Timestamp GIT API。Timestamp GIT 永远不会收到代码，永远不会读取源仓库，除了哈希之外什么都看不到。

从那时起，夜间锚定流水线是相同的：哈希队列、清单、Merkle 树、OpenTimestamps 证明、比特币锚定，以及将证明交付回你的目标仓库。

监控与故障处理

自动化并不意味着盲目信任。你应该能够看到系统正在工作，并且在出现问题时应该有明确的处理路径。

仓库状态仪表板

每个被监控的仓库都有一个状态页面，显示：

证明寿命，包括最早的锚定日期。
每日锚定规律性。
与每个时间戳关联的比特币区块和交易数据。
锚定天数的日历热力图。
可下载的审计 CSV 和 PDF 证书报告。

你还可以通过公共 API 查询状态：

curl -s https://timestampgit.dev/api/statusLast/$GITHUB_USER/$GITHUB_REPO | jq .

私有仓库在状态 URL 中附加加密的 HMAC。只有授权用户可以查看私有仓库的时间戳，且 HMAC 特定于服务器实例。

README 徽章

Timestamp GIT 为你的 README 提供可嵌入的徽章。徽章显示当前的验证状态，任何人点击都可以从链接页面验证时间戳。这对于开源项目以及希望在不暴露私有代码的情况下公开展示工作证明的机构非常有用。

审计与合规导出

为了合规或法律审查，你可以下载：

完整的审计账本（CSV 格式）。
特定日期的 PDF 证书。

这些文件为你提供了链下记录，与仓库中的密码学回执互为补充。

如果提交被遗漏了怎么办？

如果提交未在预期的夜间批次中处理，排队的哈希会保留在时间戳队列中，并在下一次运行中被获取。仓库状态仪表板是检查缺口或不规律性的首选位置。如果仓库持续显示缺失天数，请在依赖受影响范围进行法律主张之前联系支持。

自托管 Docker 选项

对于气隙环境或需要最大运营控制的情况，Timestamp GIT 以 Docker 镜像形式提供。自托管实例使用相同的 GitHub App 工作流，但运行在你拥有的基础设施上。

一个最小的 Docker Compose 设置如下：

services:
  timestampgit:
    image: rue1401/timestampgit:prod
    ports:
      - "8080:8080"
    volumes:
      - ./data:/app/data
    restart: unless-stopped
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped

使用以下命令启动：

docker compose pull
docker compose up -d
docker compose logs -f timestampgit

启动后，应用可在 http://localhost:8080 访问。首次启动时，设置向导会引导你连接 GitHub App 并配置实例。提供限时演示许可证用于评估。

自动时间戳的最佳实践

自动化消除了重复性工作，但一些习惯会让你的时间戳历史更加可靠。

频繁提交。 流水线每天锚定批次。如果你每月只提交一次，你创建的证明点更少，锚定之间的间隔更大。定期提交会创建密集、连续的现有技术记录。

使用有意义的提交信息。 被时间戳的是提交哈希，但面向人类的审计轨迹仍然重要。在争议中，Implement cache warming for API responses 这样的信息比 fix stuff 有用得多。

将 .ots 回执与源代码分开。 将时间戳分支或影子仓库视为仅追加的证据存储。避免编辑、压缩或删除它。

定期验证样本。 至少每季度一次，打开一个代表性时间戳的公开验证页面，确认 Merkle 证明正确解析。这可以在你需要证据之前发现配置漂移。

对敏感项目使用企业 ZK 模式。 如果仓库包含商业机密、内部工具或未发布的产品逻辑，企业 ZK 模式是最强的默认选择。Timestamp GIT 只能看到提交哈希，你的代码永远不会离开你的环境。

对受监管环境考虑 Docker 自托管。 如果你需要气隙操作或对 GitHub App 连接的完全控制，请使用 Docker 镜像自托管。

常见问题

自动时间戳如何与 GitHub App 配合工作？

一旦你安装了 Timestamp GIT GitHub App 并选择仓库，该应用会通过 webhook 自动检测新提交。每晚，它会批量处理所有提交哈希，创建 Merkle 树，并使用 OpenTimestamps 将根锚定到比特币区块链中。证明回执（.ots 文件）随后被推送回你仓库中的专用分支——无需手动步骤。

我的源代码是否会暴露给 Timestamp GIT？

不会。Timestamp GIT 只处理 Git 提交哈希，而不是实际的源代码。在标准模式下，GitHub App 需要仓库的读取权限来获取提交哈希，但它永远不会读取文件内容。在企业 ZK 模式下，GitHub Action 在你的基础设施上运行，仅将提交哈希推送到 API，因此 Timestamp GIT 对你的代码零访问权限。

如果 Timestamp GIT 倒闭了怎么办？

你的时间戳永远有效。证明锚定在比特币区块链中，仅基于 SHA-256 和比特币区块数据。即使 Timestamp GIT 不复存在，你也可以使用标准的 OpenTimestamps 工具独立验证它们。.ots 回执文件存储在你的仓库中，所以你始终拥有它们。

我可以在私有仓库中使用 Timestamp GIT 吗？

可以。Pro 和 Enterprise 计划支持私有仓库。对于私有仓库，状态徽章和验证链接包含加密的 HMAC，因此只有授权用户可以查看时间戳状态。建议使用企业 ZK 模式以获得最大隐私，因为它不需要对源仓库的读取权限。

设置后即可高枕无忧

手动时间戳之所以失败，是因为它依赖于有人记得去做。密码学现有技术的价值来自数月乃至数年的持续性，而不是一次性的英雄式努力。

Timestamp GIT 将这种持续性转化为基础设施。安装一次 GitHub App，连接你的仓库，夜间工作进程就会处理指纹提取、批处理、比特币锚定和证明交付。你获得不可篡改的现有技术证明，而无需持续的运营负担。

免费层覆盖公共仓库。Pro 以每月 49 美元的价格增加私有仓库支持，企业 ZK 模式每月 199 美元，包含 GitHub Action 工作流。对于气隙或受监管环境，还提供 Docker 自托管许可证。

今天就开始构建你的密码学现有技术组合：安装 Timestamp GIT GitHub App 并连接你的第一个仓库。

Timestamp automatici per i commit Git con una GitHub App