Timestamp GIT Secure your prior art without exposing code

← All posts

2026-09-04

使用 GitHub 应用自动化 Git 提交时间戳

使用 GitHub 应用自动化 Git 提交时间戳
timestamp git blockchain proof

使用 GitHub App 自动化 Git 提交时间戳

如果你曾试图证明某个 Git 提交存在的时间，你就已经知道手动流程：提取提交哈希、构建清单、等待确认、将回执文件存储到安全的地方，然后重复。这个过程重复、容易遗忘，而且一旦涉及多个仓库或团队成员，就会彻底崩溃。

有一种更好的方式，可以用 GitHub App 自动化 Git 提交的比特币时间戳。Timestamp GIT 将存在性证明变成一项后台服务：安装一次 GitHub App，连接一个仓库，之后每个提交都会在每晚锚定到比特币区块链。你不需要运行原始协议工具、记住 cron 任务，也不需要成为区块链专家。原始的 OpenTimestamps 工作流确实存在，但手动操作是困难的方式。

本文将介绍自动化工作流、一次性设置、从提交到比特币锚定之间发生的事情，以及如何监控和使用生成的证明。

你可以消除的手动时间戳繁琐流程

手动为 Git 提交添加时间戳的流程通常如下：

  1. 等到你想起某个提交本应被加上时间戳。
  2. 从 Git 中提取提交哈希。
  3. 准备一个包含你想要证明其存在性的哈希的文件。
  4. 对该文件运行时间戳工具。
  5. 等待证明创建并确认。
  6. 将回执存储到某个持久的地方。
  7. 希望以后没有人要求你解释具体步骤。

这个工作流有三个严重问题。

首先，开发者会忘记加时间戳。存在性证明只有在时间戳创建于争议发生之前才有用。如果你在三个月后才想起来，证据的效力可能就不如它本可以达到的那样强。

其次，证明会丢失。保存在笔记本电脑、旧备份硬盘或某个随机渠道中的回执文件不构成审计轨迹。在法律或合规场景中，缺失的回执看起来就像缺失的证据。

第三，手动步骤无法扩展。独立开发者可以偶尔为发布提交加时间戳。但一个拥有 15 个仓库、多个贡献者和每日合并的初创公司，无法依赖有人每天晚上手动导出哈希。

Timestamp GIT 在托管服务背后自动化了整个 OpenTimestamps 协议。该产品不会读取你的源代码。它只收集提交哈希，进行批量处理，并创建嵌入比特币区块链的密码学证明。你永远不需要接触命令行，不需要构建 Merkle 树，也不需要盯着确认过程。

一次性设置：连接你的仓库

设置路径的设计目标是完成一次之后就可以忘记。

你首先安装 Timestamp GIT GitHub App，然后选择你想要监控的仓库。公共仓库可以享受免费的 Open Source 计划。私有仓库则可通过 Pro Agency 或 Enterprise ZK 计划使用。

Timestamp GIT 提供两种部署模式。

标准模式

在标准模式下，GitHub App 通过 GitHub webhook 监控你的仓库。当出现新提交时，该应用只读取 HEAD 提交哈希。

GitHub 权限要求对源仓库具有只读访问权限，因为 GitHub 不提供仅提交哈希的访问范围。Timestamp GIT 还需要对将写入证明的目标仓库具有读写访问权限。证明分支可以位于同一仓库中，也可以位于单独的影子仓库中。

重要的一点是：你的源代码永远不会被读取、复制或存储。只有提交哈希进入 Timestamp GIT 管道。

企业 ZK 模式

企业 ZK 模式适用于无法向第三方授予任何仓库读取权限的团队。取而代之的是，一个 12 行的 GitHub Action 在你自己的基础设施上运行，只将提交哈希推送到 Timestamp GIT API。

在此模式下，Timestamp GIT 只需要对存储证明的目标仓库具有读写访问权限。它不需要对源仓库的读取权限。你的源代码永远不会离开你的环境。

初始连接完成后，就没有任何手动步骤了。被监控仓库的每个提交都会被自动捕获。

自动化管道：从提交到比特币锚定

仓库连接后，自动化管道会处理其余工作。

管道的工作方式如下：

  1. 提交检测
    GitHub App 通过 webhook 检测新提交，或者你的 GitHub Action 将提交哈希推送到 API。

  2. 哈希队列
    提交哈希存储在内存键值存储中，以便进行批量处理。

  3. 每晚批量处理
    每晚，一个工作进程将待处理的哈希分组，并为每个仓库创建一个清单 .txt 文件。

  4. Merkle 树和 OpenTimestamps
    Timestamp GIT 原生构建 Merkle 树，使用公共日历创建 OpenTimestamps 证明，并将 Merkle 根锚定到比特币区块链。

  5. 证明交付
    清单和 .ots 回执文件被推送回专门的时间戳分支或影子仓库。

比特币确认通常需要几个小时，一般在三小时左右。这意味着证明通常在每晚批量提交后的第二天可用。

你可以通过公共 API 检查仓库的当前状态：

curl -s https://timestampgit.dev/api/statusLast/acme/widget-api

curl -s https://timestampgit.dev/api/statusCount/acme/widget-api

curl -s https://timestampgit.dev/api/statusSummary/acme/widget-api

私有仓库会在这些 URL 后附加加密的 HMAC，因此只有授权用户才能查看状态。该 HMAC 特定于 Timestamp GIT 服务器实例。

API 还提供验证和报告端点：

  • GET /api/verify/{user}/{repo}/{date} 返回特定日期的完整 Merkle 链数据，用于本地验证。
  • GET /api/audit/{user}/{repo} 以 CSV 格式下载完整审计账本。
  • GET /api/report/{user}/{repo}/{date} 下载特定日期的 PDF 证书。

仓库管理端点 GET /api/repos/{user} 在 GitHub App 安装后列出被监控的仓库。

对于企业 ZK 模式，设置向导会提供一个签名 URL。GitHub Action 只将提交标识符发送到该 URL。该工作流有意保持精简，除了 GitHub Actions 中已有的事件负载外，不需要检出源代码。

监控与故障处理

自动化应该是可观测的。Timestamp GIT 为每个仓库提供一个公共状态仪表板。

仪表板包括：

  • 证明持久性
  • 最早锚定日期
  • 每日规律性
  • 比特币区块和交易数据
  • 日历热力图
  • 可下载的审计 CSV
  • PDF 证书下载

你还可以在 README 中嵌入验证徽章。经过身份验证的 GET /api/badgeLink/{user}/{repo} 端点返回徽章 URL 和可直接用于 Shields.io 的 Markdown 片段。徽章公开显示验证状态并链接到验证页面。

如果比特币确认时间超过预期，状态仪表板会显示证明在流程中的位置。由于系统每晚批量处理，确认缓慢通常意味着证明比正常情况晚几个小时出现，而不是消失。队列中的哈希保留在管道中，你可以查看状态页面了解当前状态。

重要的保证是：你的证明不依赖于 Timestamp GIT 持续可用。.ots 文件存储在你的仓库中，证明仅依赖 SHA-256 和比特币区块数据。即使公司消失，你也可以在本地验证它。

自动化时间戳的最佳实践

自动化消除了手动负担，但一些习惯可以让证据更加有力。

为每个提交加时间戳，而不仅仅是发布。
发布是有用的里程碑，但连续的提交哈希链会创建更丰富的记录。如果争议涉及某个具体的实现细节，发布级别的时间戳可能过于粗糙。

使用专用的影子仓库存储证明。
将 .ots 文件和清单文件放在单独的证明仓库中，可以让主仓库保持整洁。这也使审计收集更加容易，因为所有证明数据都集中在一个地方。

考虑为隔离环境使用 Docker 自托管。
Timestamp GIT 以 Docker 镜像形式提供，适用于需要最大控制权的团队。快速启动配置如下：

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 并配置实例。Docker 许可证页面提供限时演示许可证。

定期下载审计报告。
将 CSV 审计账本和 PDF 证书视为法律文件。将它们与其他知识产权保护记录一起存储。不要等到争议发生才开始收集证据。

将时间戳与其他知识产权保护策略结合使用。
时间戳不能替代专利、合同或商业秘密政策。它是使这些其他策略更难被质疑的密码学证明。

常见问题

GitHub App 需要访问我的源代码吗？

不需要。在标准模式下，GitHub App 只读取 HEAD 提交哈希，而不是代码本身。在企业 ZK 模式下，你基础设施上的 GitHub Action 只将提交哈希推送到 API，因此源代码永远不会离开你的环境。

提交被加上时间戳需要多长时间？

提交每晚批量处理。比特币锚定过程通常在批量提交后需要几个小时，因此证明通常在第二天可用。你可以查看状态仪表板获取实时更新。

我可以在不依赖 Timestamp GIT 的情况下验证时间戳吗？

可以。证明是标准的 OpenTimestamps .ots 文件，可以使用公共工具和比特币区块链独立验证。Timestamp GIT 还提供基于浏览器的验证页面和可下载的 PDF 证书。

如果 Timestamp GIT 倒闭了怎么办？

你的证明仍然有效，因为它们锚定在比特币区块链中，并且只使用 SHA-256 和 OpenTimestamps 等开放标准。你可以随时离线验证它们，.ots 文件存储在你的仓库中。

自动化证明，保留控制权

手动时间戳在内部推销很容易，但在实践中很难持续。存在性证明的价值来自一致性：每个提交、每一天，没有缺失的回执。

Timestamp GIT 将其变成后台流程。安装一次 GitHub App，连接你的仓库，每晚管道就会处理提交哈希、Merkle 树、OpenTimestamps 证明、比特币锚定和证明交付。你通过仪表板、徽章、CSV 审计和 PDF 证书监控结果。

公共仓库可以免费开始使用。私有仓库由 Pro Agency 和 Enterprise ZK 计划覆盖。如果你需要隔离控制，Docker 自托管许可证可以在你自己的基础设施中运行相同的自动化。

从 Timestamp GIT 开始，让存在性证明成为你提交工作流的常规组成部分。

相关文章

EU label: AI-generated content