跳过 CLI：一种更好的 Git 提交时间戳方案

如果你正在寻找手动 OpenTimestamps 的替代方案，这个决定可能更多关乎运维，而非密码学。OpenTimestamps 协议完成了最困难的部分：它将一个哈希锚定到比特币区块链中，以便日后你可以证明某份数据在特定时间点确实存在。真正的问题在于，谁来管理围绕这一证明的工作流程。

手动时间戳需要命令行工具、脚本、计划管理、回执存储，以及一套可重复的验证流程。Timestamp GIT 则采取了相反的方式：它是一个托管 SaaS 和 GitHub App，能够完全自动化并隐藏 OpenTimestamps 协议。你只需安装一次 GitHub App，连接一个仓库，此后每次提交都会在每晚自动锚定到比特币中。

本文对这两条路径进行比较，以便你为自己的开发工作流、团队以及合规要求做出正确选择。

选择：手动 OpenTimestamps 还是托管自动化

核心购买决策很简单：你是想自己运营一条时间戳流水线，还是想让存在性证明成为你日常 Git 工作流的一个自然副产品？

手动 OpenTimestamps 是可以跑通的。你安装 OpenTimestamps 客户端，针对提交哈希执行时间戳操作，存储生成的 .ots 回执文件，安排后续的日历见证，并最终对照比特币区块链验证这些回执。这套工作流很强大，但也容易被遗忘。一次被跳过的 cron 任务、一份丢失的回执文件，或是一个过期的本地客户端，都可能在本应连续的证据链中制造缺口。

Timestamp GIT 专为不想维护这套机制而构建。它只读取你的 Git 提交哈希，每天批量处理哈希，创建 OpenTimestamps 证明，将 Merkle 根锚定到比特币中，并把回执文件推送回你仓库中的一个专用分支。密码学强度相同，但运维负担被移除了。

现状：开发者如今如何为 Git 提交打时间戳

大多数团队在尝试为软件提交建立在先技术证明时，通常会落入以下三类之一。

手动 OpenTimestamps

传统路线是在本地安装 OpenTimestamps 工具，并自行针对提交哈希运行。这通常意味着：

• 在开发者机器或服务器上安装并维护 OpenTimestamps 客户端
• 针对单个提交哈希执行时间戳操作
• 跟踪 .ots 回执文件
• 等待比特币网络确认锚定
• 之后验证每个证明，通常通过命令行完成

这种方式免费，并且让你拥有完全控制权，但它没有 GitHub 原生的自动化。你必须记得去做、编写脚本，或者围绕它构建自己的调度机制。

第三方时间戳服务

一些服务提供用于数据时间戳的 API 或 Web 界面。它们可以消除部分手动负担，但往往不能原生地理解 Git。这意味着如果你希望每次提交都自动受到保护，仍然需要编写自定义集成代码。一些服务还要求你信任它们的存储或验证模型。

Timestamp GIT

Timestamp GIT 是一个托管 SaaS + GitHub App，能够完全自动化并隐藏 OpenTimestamps 协议。你无需安装协议客户端或编写自定义集成代码，只需安装一次 GitHub App，并选择你想要监控的仓库。

从那时起，Timestamp GIT 会：

• 自动检测新提交
• 仅提取提交哈希
• 每晚批量处理这些哈希
• 根据每日哈希构建 Merkle 树
• 使用公共 OTS 日历创建 OpenTimestamps 证明
• 将 Merkle 根锚定到比特币区块链中
• 将清单和 .ots 回执文件推送回时间戳分支或影子仓库

你永远不需要运行协议命令、手动管理回执文件，或记得触发时间戳任务。GitHub App 会自动完成这一切。

对于隔离或自托管需求，Timestamp GIT 也提供 Docker 镜像。自托管选项将在本文末尾的相关指南中介绍。

选择标准：选择时间戳方案时哪些因素最重要

在比较手动 OpenTimestamps 与托管替代方案时，请关注五个影响实际采用的标准。

设置便捷性与持续维护

手动 OpenTimestamps 从安装和配置开始。然后你还需要脚本、调度、存储位置，以及一个负责维护流水线的人。随着时间推移，依赖更新和机器变更都会增加摩擦。

Timestamp GIT 从安装 GitHub App 开始。你选择仓库，每晚的锚定流水线就会启动，无需本地配置。开发者机器上无需安装任何东西，证明交付也会自动完成。

自动化

关键问题是每次提交是否都能获得时间戳。使用手动 OpenTimestamps，这取决于你自己的自动化。没有自动化，你可能只会保护选定的提交，或者在赶工期间忘记处理。

Timestamp GIT 会自动监控每次提交。一旦仓库连接，新提交就会进入队列并在每晚锚定。比特币区块链中的确认需要几个小时，通常约三小时，因此证明写入自然会滞后于提交本身。

安全性与零知识

手动 OpenTimestamps 在本地运行，因此你的源代码永远不会离开机器。这很好，但该过程仍然依赖于本地的运维纪律。

Timestamp GIT 不会看到、复制或存储你的源代码。它只对 Git 哈希进行数学盖章。在标准模式下，GitHub App 只读取被监控仓库的 HEAD 提交哈希。在企业零知识模式下，一个 GitHub Action 在你的环境中运行，并仅将提交哈希推送到 Timestamp GIT API。这意味着你的源代码根本不会离开你的基础设施。

与现有工作流的集成

手动 OpenTimestamps 生成 .ots 文件，你必须手动存储和出示。这对单个工程师来说没问题，但它不太适合团队工作流。

Timestamp GIT 直接与 GitHub 集成。你可以获得：

• 自动将证明交付到专用分支或影子仓库
• 可嵌入 README 文件的验证徽章
• 每个仓库的公开状态仪表盘
• 可下载的审计 CSV 文件
• 特定日期的 PDF 证书
• 用于状态、验证和仓库管理的 REST API

价格与可扩展性

就软件成本而言，手动 OpenTimestamps 是免费的，但它会消耗工程时间。编写脚本、监控和排查手动流水线问题的成本，可能超过托管方案的价格。

Timestamp GIT 的定价从公共仓库的免费层开始。Pro Agency 为私有仓库提供，价格为 $49/月；Enterprise ZK 为 $199/月，包含 GitHub Actions 和零知识哈希推送。

并排比较：手动 OpenTimestamps 与 Timestamp GIT

两种方法都依赖相同的底层 OpenTimestamps 协议和比特币锚定。变化的是可用性。

关键点在于，Timestamp GIT 并不会创建更弱的时间戳。无论你是手动创建证明，还是通过 GitHub App 创建，一个通过 OpenTimestamps 锚定到比特币中的 SHA-256 指纹都能提供相同的数学安全性。区别在于，Timestamp GIT 让你无需记得运行任何东西，就能获得持续覆盖。

一个微小但重要的细节关系到零知识声明。GitHub App 所需的全部内容只是被监控仓库的 HEAD 提交哈希。该值在任何 Git 检出中看起来像这样：

git rev-parse HEAD
# a1b2c3d4e5f67890abcdef1234567890abcdef12

这个哈希是标准模式从源仓库读取的唯一数据。它是一个密码学指纹，而不是你工作的副本。

结论：谁应该选择哪种方案

选择手动 OpenTimestamps，如果

• 你是一名熟悉命令行工具的独立开发者
• 你只需要为特定里程碑偶尔打时间戳
• 你想要完全的本地控制，不依赖任何第三方服务
• 你愿意永远负责回执存储和验证

选择 Timestamp GIT，如果

• 你是一个需要为每次提交提供持续证明的团队、代理机构或初创公司
• 你不想构建或维护时间戳脚本
• 你需要零知识保证，确保源代码永远不会离开你的环境
• 你需要专业的验证报告、徽章和审计账本，用于法律或合规目的

隔离环境的中间地带

对于有严格网络要求的企业，Timestamp GIT 提供了 Docker 自托管选项。你可以在自己的基础设施中运行该服务，并且只向它提供提交哈希。Docker Compose 的起点是：

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

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

当你需要 Timestamp GIT 的自动化，但又无法使用托管云服务时，这个选项非常有用。

开始使用 Timestamp GIT（托管替代方案）

托管路径刻意设计得很简单。

1. 安装 Timestamp GIT GitHub App
2. 选择你想要监控的仓库
3. 让每晚的锚定流程自动开始

在第一批证明写入之后，你可以将验证徽章添加到 README 中，并与相关方分享公开状态页面。状态页面会显示证明存续时间、最早锚定日期、每日规律性、比特币区块和交易数据，以及日历热力图。你还可以下载审计 CSV 和特定日期的 PDF 证书。

如需详细设置指南，请参阅如何在不使用 CLI 工具的情况下为 Git 提交加密打时间戳。有关计划详情（包括免费公共仓库层），请参阅Timestamp GIT 定价：适合每位开发者的计划。

从 Timestamp GIT 的免费层开始，连接一个公共仓库，亲身体验自动化工作流。

常见问题

Timestamp GIT 是否与手动运行 OpenTimestamps 一样安全？

是的。Timestamp GIT 使用相同的 OpenTimestamps 协议，并将提交哈希锚定到比特币区块链中。密码学证明完全相同。区别在于，Timestamp GIT 自动化了该过程，并为你管理回执。

Timestamp GIT 会看到我的源代码吗？

不会。Timestamp GIT 只处理 Git 提交哈希，从不接触实际代码。在企业零知识模式下，哈希通过 GitHub Action 从你的环境推送，因此你的源代码永远不会离开你的基础设施。

我能否在不依赖 Timestamp GIT 服务器的情况下验证时间戳？

可以。你可以下载 .ots 回执文件，并使用标准 OpenTimestamps 工具对照比特币区块链独立验证。Timestamp GIT 还提供基于 Web 的验证页面和 PDF 证书，方便使用。

如果我需要为私有仓库中的提交打时间戳怎么办？

Timestamp GIT 在付费计划上支持私有仓库：Pro Agency 和 Enterprise ZK。在标准模式下，GitHub App 需要对源仓库的读取权限，但企业零知识模式通过使用 GitHub Action 仅推送提交哈希，连这一点也消除了。

结语

手动 OpenTimestamps 是合理的，但它要求你运营一条证明流水线。Timestamp GIT 通过一个托管 GitHub App 为你提供相同的密码学保证，几分钟即可安装完成，并且每晚自动运行。对于需要在不增加运维开销的情况下获得在先技术证明的团队和公司来说，它是手动 OpenTimestamps 更实用的替代方案。

选择与你团队实际交付软件方式相匹配的工作流。如果你希望为每次提交获得自动、持续、可上法庭的证明，连接一个仓库，让每晚的锚定流水线处理剩下的一切。

相关文章

• 使用 Docker 自托管 Git 时间戳：一份指南
• 如何在不使用 CLI 工具的情况下为 Git 提交加密打时间戳
• Timestamp GIT 定价：适合每位开发者的计划