Timestamp GIT Secure your prior art without exposing code

← All posts

2026-09-09

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

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

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

如果你曾经尝试过证明某个 Git 提交是何时发生的，你就会知道那套手动流程：为提交哈希创建加密收据，将 .ots 文件存储在某个持久化的位置，把收据映射回对应的提交，然后对每个重要的分支和仓库重复这一过程。漏掉一个提交，你的在先技术记录就会出现缺口。

Timestamp GIT 用一款 GitHub App 取代了这套流程，自动为 Git 提交添加时间戳。本文关注的是自动化路径，而非底层的加密概念。关于存在性证明的背景知识及其重要性，请参阅代码的存在性证明：它是什么以及为什么重要。

你可以消除的手动时间戳琐事

手动添加时间戳通常是因为一些乏味的原因而失败，而非安全问题。

  • 你忘记为重要的功能分支添加时间戳。
  • 收据散落在笔记本电脑、CI 工件和各种随机文件夹中。
  • 收据文件与具体提交之间没有清晰的映射关系。
  • 不同的团队成员使用不同的流程，或者根本没有流程。
  • 当争议真正发生时，你才发现收据从未被创建。

困难的方式是直接使用 OpenTimestamps：安装工具，手动为提交哈希添加时间戳，并自行存储收据文件。这种方法在技术上是可行的，但它是一项与真正的开发工作争夺时间的琐事。

Timestamp GIT 帮你卸下了这个负担。它是一个托管 SaaS 和 GitHub App，完全自动化并隐藏了 OpenTimestamps 协议。安装之后，它会监视你的仓库，收集提交哈希，并每晚将它们锚定到比特币区块链中。无需 CLI 工具，无需手动管理收据，无需记忆。

一次性设置：将你的仓库连接到 GitHub App

设置模式刻意设计得很简单：安装一次，连接仓库，然后就不用管了。

使用 GitHub App 的标准模式：

  1. 从 GitHub Marketplace 安装 Timestamp GIT GitHub App。
  2. 授予对你想要监控的仓库的访问权限。
  3. 选择证明的存储位置：同一仓库中的专用分支或单独的影子仓库。
  4. 完成。

安装后，GitHub App 会自动通过 webhook 开始监控新的提交。无需修改代码，无需本地配置文件，也无需在开发者机器上安装任何东西。

标准模式下的权限：

  • 该应用需要对源仓库具有只读访问权限，以便读取 HEAD 提交哈希。
  • 它需要对存储证明文件的目标仓库或分支具有读写访问权限。
  • 它永远不会读取或存储你的实际源代码。

适用于零知识环境的企业 ZK 模式：

如果你的安全策略要求源代码绝不能离开你的基础设施，你可以使用企业 ZK 模式。一个 12 行的 GitHub Action 在你这边运行，仅将提交哈希推送到 Timestamp GIT API。在这种模式下，Timestamp GIT 完全不需要对源仓库的读取权限——只需要对存储证明的目标仓库具有读写权限。

这一区别对合规团队很重要：标准模式从 GitHub 读取提交哈希，而企业 ZK 模式仅从你的 GitHub Action 发送哈希。

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

设置完成后，流水线无需人工干预即可运行。

每晚，一个工作进程会收集当天待处理的提交哈希，并对它们进行批处理：

  1. 提交哈希由 GitHub App 检测到，或由你的企业 ZK Action 推送。
  2. 哈希在内存队列中等待，直到夜间运行。
  3. 午夜 cron 工作进程按仓库对待处理哈希进行分组。
  4. 工作进程为每个仓库创建清单文件。
  5. 它从每日批次构建一棵 Merkle 树。
  6. 它使用公共 OTS 日历创建 OpenTimestamps 证明。
  7. Merkle 根被锚定到比特币区块中。

然后，清单和 .ots 收据文件被推送回你的专用时间戳分支或影子仓库。

一个重要的时间说明：比特币确认需要几个小时，通常大约三小时。由于批处理在午夜运行，锚定稍后完成，证明通常会在第二天出现。这种延迟不是故障——这是比特币网络在做使时间戳不可变的工作。

你可以通过 REST API 检查最后的锚定状态：

# 最后锚定的比特币区块信息
curl -s https://timestampgit.dev/api/statusLast/acme/webapp

# 已提交/已加时间戳的提交总数
curl -s https://timestampgit.dev/api/statusCount/acme/webapp

# Shields.io 徽章使用的综合摘要
curl -s https://timestampgit.dev/api/statusSummary/acme/webapp

将 acme/webapp 替换为你的 GitHub 用户或组织名以及仓库名。

对于公开 README，你可以嵌入一个验证徽章。安装后，仓库连接页面会提供 Markdown 代码片段。一个典型的徽章如下所示：

[![Timestamp GIT](https://timestampgit.dev/api/statusSummary/acme/webapp)](https://timestampgit.dev/status/acme/webapp)

对于私有仓库，状态 URL 使用加密的 HMAC 进行保护。只有授权用户才能查看这些仓库的状态，且 HMAC 特定于服务器实例。

监控与故障处理：保持你的证明健康

自动化并不意味着忽视系统。它意味着监控结果，而不是手动执行任务。

仓库状态页面是你的主要健康仪表板。它显示：

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

对于程序化监控，公共 API 端点覆盖了常见情况：

# 检查最近锚定的区块
curl -s https://timestampgit.dev/api/statusLast/acme/webapp

# 统计已加时间戳的提交数量
curl -s https://timestampgit.dev/api/statusCount/acme/webapp

# 获取用于脚本或 Shields.io 的综合摘要
curl -s https://timestampgit.dev/api/statusSummary/acme/webapp

这些端点可以接入你现有的正常运行时间监控、内部仪表板或 CI 检查。例如，一个定时脚本可以每天调用一次 statusLast，并在预期的锚定日期缺失时发出警报。

常见的故障场景包括：

  • 在 GitHub 中撤销了仓库访问权限。
  • GitHub App 被卸载。
  • GitHub 与 Timestamp GIT 服务之间的网络问题。

这些故障会在仓库状态页面上显示出来，而不是静默失败。由于提交哈希按日期分批处理，一次错过的夜间运行可以在下一次成功的批次中拾取待处理的哈希。

为了合规和记录保存，请定期下载审计 CSV 和 PDF 证书。将它们与其他知识产权文档一起存储在你的法律档案中。

自动化 Git 时间戳的最佳实践

一旦自动化就位，一些习惯将使你的在先技术记录更加可靠。

为所有仓库添加时间戳，包括私有仓库。 许多团队只为面向公众的项目添加时间戳。但专利流氓和雇佣纠纷通常针对内部系统和商业机密。私有仓库同样重要，甚至更为重要。

将证明文件排除在主源代码分支之外。 使用专用的时间戳分支或单独的影子仓库。这样可以保持 main 分支的整洁，同时为审计人员提供一个查找 .ots 收据和清单文件的单一位置。

在 README 中嵌入验证徽章。 一个可见的徽章告诉潜在的侵权者，你的提交历史已锚定在比特币中。它不仅仅是装饰；它是一种低成本的威慑。

在源代码必须保留在内部的情况下使用企业 ZK 模式。 如果你的合规团队禁止第三方对源仓库的读取访问，GitHub Action 方法仅将提交哈希发送到 Timestamp GIT API。

对于隔离或自托管环境，使用 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 许可证页面提供限时演示许可证。

定期下载审计报告。 不要等到法律纠纷发生才开始收集证据。每季度或每月导出一次只需几分钟，就能为你提供一个离线存档。

常见问题

GitHub App 如何自动为我的提交添加时间戳？

安装后，Timestamp GIT GitHub App 通过 webhook 监控你的仓库中的新提交。每晚，它收集当天所有的提交哈希，创建一棵 Merkle 树，并使用 OpenTimestamps 协议将根锚定到比特币区块链中。然后证明会自动推送回你的仓库。无需手动步骤。

GitHub App 能访问我的源代码吗？

在标准模式下，该应用需要对源仓库的只读访问权限以读取提交哈希，但它永远不会读取或存储你的实际源代码。为了最大程度的隐私保护，企业 ZK 模式使用一个 GitHub Action，仅将提交哈希推送到 Timestamp GIT API，因此你的源代码永远不会离开你的环境。

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

可以。Pro 和 Enterprise 计划支持私有仓库。该应用可以将证明存储在影子仓库或专用分支中，并且私有仓库的状态端点访问受 HMAC 保护。

如何验证我的提交已被添加时间戳？

你可以通过公共状态仪表板、API 端点（如 /api/statusLast）进行验证，或者下载 .ots 收据并使用标准的 OpenTimestamps 验证工具对照比特币区块链进行验证。验证是独立的，不依赖于 Timestamp GIT 的服务器。

结论：设置好就不用管了

自动化的 Git 时间戳将问题从“我是否记得为这个提交添加时间戳？”转变为“夜间锚定是否出现在我的仪表板中？”

Timestamp GIT 在幕后处理整个 OpenTimestamps 协议。你只需安装一次 GitHub App，连接你的仓库，然后让夜间流水线将提交哈希锚定到比特币中。其结果是不可变的、可供法庭使用的在先技术证据，而无需养成新的手动习惯。

从公共仓库的免费计划开始，对于私有仓库升级到 Pro Agency，或者在源代码必须保留在基础设施内部时使用 Enterprise ZK。自托管用户可以通过部署 Docker 镜像来获得完全控制。

立即在 Timestamp GIT 安装 GitHub App，让时间戳成为你的仓库自动完成的事情。

相关文章

EU label: AI-generated content