← All posts
几分钟内设置自动 Git 提交时间戳

几分钟内设置自动 Git 提交时间戳

timestamp git blockchain proof

几分钟内设置自动 Git 提交时间戳

如果你曾试图证明某段代码是何时编写的，你就会知道那套手动流程：在每次重要提交后运行时间戳命令，把凭证存放在某个持久的地方，记住哪些文件已被覆盖，并祈祷你没有漏掉那个日后成为争议焦点的提交。这套流程重复、容易出错，而且几乎不可能在真实项目的整个生命周期中持续执行。

自动 Git 提交时间戳彻底消除了这一负担。借助合适的托管服务，它变成了一次性设置，只需几分钟——而不是一项持续的苦差事。Timestamp GIT 正好提供了这样的能力：一个 GitHub App，每晚将你的提交哈希锚定到比特币区块链上，你无需触碰命令行，也无需管理凭证文件。

本文将介绍设置流程、自动化流水线、监控以及最佳实践，让你可以一劳永逸。

你可以消除的重复性任务

传统的时间戳工作流迫使开发者陷入手动步骤的循环：

这是脆弱的。人会忘记。凭证会丢失。当流程依赖于记忆和纪律时，“我在此日期编写了这段代码”的整个证明理念就会崩塌。

你可以自己运行底层的 OpenTimestamps 协议，但那意味着围绕 CLI 命令编写脚本、处理凭证、追踪区块链确认。那是困难的方式——而这正是 Timestamp GIT 所消除的。

Timestamp GIT 自动化了每一步：一旦安装了 GitHub App，受监控仓库中的每一次提交都会被收集、批量处理，并每晚锚定到比特币。你永远不需要运行命令、管理凭证或记得给任何东西打时间戳。这是最真实意义上的自动 Git 提交时间戳。

有关安装本身的详细指南，请参阅安装 GitHub App 实现自动代码时间戳。本文重点介绍端到端设置以及之后的自动化运行。

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

设置只需几分钟。流程如下：

  1. 从 GitHub Marketplace 安装 Timestamp GIT GitHub App。
  2. 选择你要监控的仓库。 根据你的套餐，支持公共或私有仓库。
  3. 选择你的权限模式：
    • 标准模式：GitHub App 需要对源仓库的只读访问权限。它只读取 HEAD 提交哈希——从不读取文件内容。
    • 企业 ZK 模式：完全不读取源代码。你基础设施上的一个 GitHub Action 仅将提交哈希推送到 Timestamp GIT API。你的源代码永远不会离开你的环境。
  4. 确认安装。

之后就没有任何手动步骤了。系统会监控仓库，自动检测新提交，并每晚运行时间戳流水线。

如果你通过 Docker 镜像自托管，设置向导会引导你完成 GitHub App 的连接和实例配置。对于大多数团队来说，SaaS GitHub App 是最快的路径。

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

连接仓库后会发生以下事情：

每晚批量处理

每个提交哈希在到达时被存储在一个内存队列中。每晚，一个工作进程运行并将每个仓库的所有待处理哈希分组。它创建清单文件（.txt），原生构建 Merkle 树，并使用公共日历生成 OpenTimestamps 证明。

每日批次的 Merkle 根随后通过 OpenTimestamps 协议锚定到比特币区块中。一旦在区块链上确认，时间戳就变得不可变——任何实体，包括 Timestamp GIT，都无法更改或伪造它。

证明交付

锚定确认后（通常约 3 小时），Timestamp GIT 将清单和 .ots 凭证文件推送回你的仓库，存放在专用的 timestamps 分支或影子仓库中。你无需手动获取任何东西；证明与你的代码一起进行版本管理。

12 行代码实现企业 ZK 模式

如果你无法授予源代码的读取权限，企业 ZK 模式使用一个在你基础设施上运行的 GitHub Action。它仅将提交哈希推送到 API。以下是一个最小可运行示例：

name: Timestamp commit hash
on: [push]
jobs:
  anchor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          curl -X POST "https://timestampgit.dev/api/timestamp/${{ github.repository }}/${{ github.ref_name }}/${{ github.sha }}/${{ secrets.TIMESTAMPGIT_HMAC }}"

这就是完整的 action。实际模板在企业 ZK 设置过程中提供，但原理很简单：将提交 ID 和签名 HMAC 发送到 API，除此之外没有任何东西离开你的环境。

用于状态、验证和审计的 REST API

自动化延伸到报告层面。公共端点让你无需登录仪表板即可查询证明状态：

# 最后锚定的比特币区块信息
curl https://timestampgit.dev/api/statusLast/your-org/your-repo

# 已提交/已打时间戳的提交总数
curl https://timestampgit.dev/api/statusCount/your-org/your-repo

# Shields.io 徽章的综合摘要
curl https://timestampgit.dev/api/statusSummary/your-org/your-repo

# 以 CSV 格式下载完整审计台账
curl -O https://timestampgit.dev/api/audit/your-org/your-repo

# 下载特定日期的 PDF 证书
curl -O https://timestampgit.dev/api/report/your-org/your-repo/2026-08-19

对于私有仓库，这些 URL 包含特定于你实例的加密 HMAC，因此只有授权用户才能访问状态。所有这些都是自动的——无需开发者干预。

监控与故障处理

流水线运行后，你需要了解证明状态的可视化方式以及检测问题的方法。

公共状态仪表板

每个仓库都有一个公共仪表板，位于 https://timestampgit.dev/status/{user}/{repo}。它显示：

你还可以下载审计 CSV 和任意日期的 PDF 证书。这些对于合规和离线记录保存非常有用。

可嵌入的验证徽章

Timestamp GIT 提供了可以粘贴到 README 中的徽章代码片段。徽章显示实时验证状态，并链接到一个公共验证页面，任何人都可以在那里检查 Merkle 链。该页面在浏览器中本地执行所有计算——零知识验证。

处理延迟和遗漏的天数

比特币确认需要时间，通常约 3 小时。系统会自动处理这一延迟；一旦锚定确认，你的证明就会被写入。如果你在每晚截止时间之后提交，哈希会被包含在第二天的批次中。

如果某天没有提交，则不会为该天生成时间戳。现有证明仍然有效；系统只是跳过空批次。

对于私有仓库，HMAC 签名的 URL 保护状态和验证页面的访问。只有拥有正确 HMAC 的人才能看到证明状态。

可靠时间戳的最佳实践

要充分利用自动 Git 提交时间戳，请遵循以下准则：

常见问题

自动 Git 提交时间戳是如何工作的？

Timestamp GIT 使用 GitHub App 自动检测新提交。每晚，它收集提交哈希，构建 Merkle 树，并通过 OpenTimestamps 将根锚定到比特币区块链。证明凭证（.ots 文件）被推送回你的仓库，提供不可变的存在性证据。

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

不会。在标准模式下，GitHub App 只读取提交哈希，不读取文件内容。在企业 ZK 模式下，你基础设施上的 GitHub Action 仅将哈希推送到 API，因此你的源代码永远不会离开你的环境。

如果我某天没有提交会怎样？

如果某天没有提交，则不会为该天生成时间戳。系统只锚定已发生提交的哈希。你现有的证明仍然有效，未来的提交将自动打上时间戳。

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

可以。.ots 凭证文件可以使用标准 OpenTimestamps 工具针对比特币区块链进行独立验证。Timestamp GIT 还提供了一个基于浏览器的验证页面，在本地执行所有计算。

一劳永逸

自动 Git 提交时间戳将一项繁琐、容易出错的事务变成了一个后台进程。你只需安装一次 GitHub App，连接你的仓库，每次提交就会每晚自动锚定到比特币——无需手动命令，无需凭证管理，无需记忆。

Timestamp GIT 是使这一切成为可能的托管服务。它将 OpenTimestamps 的复杂性隐藏在一个简洁的 GitHub App 背后，将证明直接交付到你的仓库，并为你提供仪表板、徽章和 API 用于验证。准备好开始了吗？安装 GitHub App，连接一个仓库，让每晚的锚定开始运行。

相关文章

Published on Timestamp GIT · Timestamp GIT
EU label: AI-generated content