Автоматическое проставление временных меток Git: как GitHub App привязывает каждый коммит

Вы делаете коммит, который имеет значение — ядро функции, авторство которой вас попросят доказать. При ручном подходе именно в этот момент ваш процесс ломается. Вы останавливаетесь, переключаете контекст и начинаете небольшой ритуал с локальными инструментами и обработкой доказательств, чтобы привязать коммит к моменту времени. Затем вы делаете это снова на следующем коммите, и на следующем, пока однажды не забудете.

В этом и заключается ловушка ручного проставления временных меток. Записи о prior art сильны ровно настолько, насколько плотны и регулярны, а записи, зависящие от человеческого процесса, не обладают ни тем, ни другим. Разработчики пропускают этот шаг в аврал, настраивают его неправильно на новой машине или вообще никогда не настраивают его в том репозитории, который в итоге оказывается важным. Пробелы в цепочке — именно то, что ищет процессуальный оппонент или аудитор.

Эта статья о том, как полностью убрать человека из этого цикла с помощью автоматического проставления временных меток Git через GitHub App. Одна установка — и каждый коммит в отслеживаемом репозитории получает отпечаток и привязывается к Bitcoin каждую ночь: машиной, по расписанию, без единой введённой команды.

Это практическое руководство по автоматизации, а не глубокое погружение в криптографию. О том, зачем это нужно, см. Защита интеллектуальной собственности: руководство для разработчиков ПО и Защита prior art для софтверных стартапов: руководство. О механике проверки доказательства позже см. Проверка временных меток кода без раскрытия исходного кода.

(Для контекста: «сырой» подход — это запуск инструментов OpenTimestamps вручную, для каждого коммита, с самостоятельным управлением отправкой в календари. Это трудный путь. Всё нижеописанное — автоматизированный путь.)

Разовая настройка: установите GitHub App и забудьте о ней

Timestamp GIT — это управляемый SaaS, построенный вокруг GitHub App. Вы устанавливаете его один раз для репозитория или целой организации, и автоматизация берёт всё на себя.

Есть два режима развёртывания, и вы выбираете исходя из того, какой объём доступа готовы предоставить:

Standard Mode (GitHub App). GitHub App читает только хеш HEAD-коммита вашего отслеживаемого репозитория — автоматически, при каждом push. Доказательства записываются в выделенную ветку того же репозитория или в отдельный теневой репозиторий. Поскольку модель разрешений GitHub не предлагает область «только хеш коммита», этот режим требует доступ на чтение к исходному репозиторию и доступ на чтение-запись к целевому репозиторию, куда попадают доказательства.

Enterprise ZK Mode (GitHub Action). Шаг сбора переносится в ваш собственный CI. GitHub Action из 12 строк выполняется на ваших раннерах, извлекает хеш HEAD и отправляет только этот хеш в API Timestamp GIT. Компромисс здесь явный: доступ на чтение остаётся у вас, а Timestamp GIT нужен доступ на чтение-запись только к целевому репозиторию. Ни исходный код, ни доступ на чтение репозитория никогда не пересекают границу.

Два момента, которые стоит отметить в настройке:

• На машины разработчиков ничего не устанавливается. Ни CLI, ни локального демона, ни расхождений в конфигурации между ноутбуками. Приложение работает на инфраструктуре GitHub и нашем бэкенде; Action выполняется на раннерах, размещённых на GitHub или собственных.
• Никакой постоянной конфигурации нет. После установки приложение обнаруживает новые коммиты через вебхуки. Никому ничего не нужно помнить.

После установки вы можете просматривать и управлять тем, какие репозитории отслеживаются, на странице ваших репозиториев.

Автоматизированный конвейер: от коммита до привязки в Bitcoin

После установки приложения вот что на самом деле происходит между git push и появлением неизменяемого файла доказательства в вашем репозитории.

1. Обнаружение коммитов и пакетная обработка

При новых коммитах срабатывает вебхук. Приложение — или ваш Action в Enterprise ZK Mode — извлекает хеш коммита и помещает его в хранилище «ключ-значение» в памяти. Это хранилище — очередь, а не реестр; оно существует исключительно для накопления хешей до запуска ночного пакета.

Перемещается только хеш. Никогда не diff, никогда не содержимое файлов, никогда не история веток.

2. Ночной cron-воркер

Каждую ночь воркер забирает все ожидающие хеши и:

1. Группирует их по репозиториям и записывает файл-манифест (.txt) для каждого репозитория.
2. Строит дерево Меркла непосредственно над пакетом.
3. Создаёт доказательства OpenTimestamps с помощью публичных серверов-календарей.
4. Привязывает корень Меркла в блокчейн Bitcoin.

Именно последний шаг делает запись неизменяемой. Как только корень подтверждён в блоке Bitcoin, никакая сущность — включая Timestamp GIT — не может изменить или подделать его задним числом.

3. Доставка доказательств

После привязки манифест и соответствующие файлы-квитанции .ots отправляются обратно в ваш репозиторий — либо в выделенную ветку timestamps, либо в теневой репозиторий.

Заложите на это несколько часов. Подтверждение Bitcoin обычно занимает около 3 часов, поэтому доказательства, как правило, появляются через несколько часов после ночного запуска, а не сразу.

Enterprise ZK Mode: единственный режим с файлом workflow

Это единственное место, где вам когда-либо придётся смотреть на YAML. Мастер настройки генерирует workflow с уже подставленными вашим эндпоинтом и секретом; выглядит это примерно так:

name: Timestamp commit hash
on: [push]
jobs:
  anchor:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1
      - name: Send HEAD hash to Timestamp GIT
        env:
          TSG_ENDPOINT: ${{ secrets.TIMESTAMPGIT_ENDPOINT }}
        run: curl -fsS -X POST "$TSG_ENDPOINT" --data "$(git rev-parse HEAD)"

Вот и вся интеграция. Если хотите углубиться в этот режим, есть отдельное руководство: GitHub Action для проставления временных меток коммитов: руководство по настройке.

Пользовательские конвейеры: ZK Commit API

Если вам нужно встроить проставление временных меток во что-то помимо стандартного потока, ZK Commit API принимает хеши коммитов напрямую. Аутентификация выполняется через HMAC — значение хеша из подписанного URL должно сопровождать запрос — так что одного утёкшего URL недостаточно, чтобы записать что-либо в ваш реестр.

Для автоматизации только на чтение публичные эндпоинты статуса проще:

# Last anchored Bitcoin block for a repo
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo

# Total stamped commit count
curl -s https://timestampgit.dev/api/statusCount/your-org/your-repo

# Combined summary (what the Shields.io badge consumes)
curl -s https://timestampgit.dev/api/statusSummary/your-org/your-repo

Мониторинг и обработка сбоев

Автоматизация, которую нельзя проверить, — это автоматизация, которой нельзя доверять в споре. Timestamp GIT раскрывает состояние вашей цепочки доказательств в трёх местах.

Публичный дашборд статуса

/status/{user}/{repo} показывает долговечность доказательств, самую раннюю дату привязки, ежедневную регулярность, а также данные блока и транзакции Bitcoin, лежащие в основе каждой привязки. Есть календарная тепловая карта, чтобы пробелы были визуально очевидны, плюс загружаемые экспорты аудита в CSV и сертификатов в PDF.

Регулярность — это метрика, за которой стоит следить. Тепловая карта с дырами — это более слабая история prior art, чем сплошная.

Значки верификации

Вы можете встроить значки Shields.io в свой README, чтобы публично отображать статус верификации. Виджет на /connected/{user}/{repo} даёт живой предпросмотр и markdown-сниппет, а /api/badgeLink/{user}/{repo} программно возвращает URL-адреса значков и сниппет.

Приватные репозитории добавляют зашифрованный HMAC к URL-адресам значков и статуса, привязанный к экземпляру сервера. Это означает, что значок всё равно отображается, но разрешить базовые данные статуса могут только авторизованные пользователи.

Когда ночной запуск завершается сбоем

Наиболее вероятный сбой — задержка подтверждения из-за перегрузки сети Bitcoin. Система повторяет попытки, а не отбрасывает пакет. Проверяйте состояние через дашборд или через API, если вы подключаете это к своей системе оповещений:

# Confirm the latest anchored block; a stale value means the last run didn't land
curl -s https://timestampgit.dev/api/statusLast/your-org/your-repo | jq .

Если вам нужны доказательства на конкретный момент времени для комплаенса, забирайте артефакты напрямую:

# Full audit ledger as CSV
curl -sO https://timestampgit.dev/api/audit/your-org/your-repo

# PDF certificate for a specific date
curl -sO https://timestampgit.dev/api/report/your-org/your-repo/2026-10-04

Любой также может независимо проверить временную метку за отдельный день через /verification/{user}/{repo}/{date}, где полное вычисление цепочки Меркла происходит локально в браузере. Никто — включая Timestamp GIT — не видит, что вы проверяете.

Среды с воздушным зазором

Если ваша модель безопасности вообще не допускает управляемый сервис, Timestamp GIT поставляется в виде Docker-образа. Быстрый старт с 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 и настройку экземпляра при первом запуске. Ограниченная по времени демонстрационная лицензия для оценки доступна на странице Docker License. Самостоятельное проставление временных меток в блокчейне с помощью Docker подробно описывает этот путь.

Лучшие практики автоматического проставления временных меток

• Коммитьте регулярно, разумными по размеру порциями. Каждый коммит добавляет лист в ежедневное дерево Меркла. Плотная цепочка — более сильная запись prior art, чем четыре гигантских коммита за квартал.
• Пишите осмысленные сообщения коммитов. Временные метки ставятся только на хеши, но во время аудита вам придётся соотносить доказательства с функциями. Хорошие сообщения делают это сопоставление тривиальным.
• Настройте оповещения о устаревших привязках. Зелёный значок должен означать, что недавний запуск прошёл успешно, а не то, что запуск был один раз в марте.
• Не трогайте workflow. Самый большой риск в автоматическом проставлении временных меток — кто-то «улучшает» конвейер. В настройке по умолчанию нет ручных шагов не просто так.
• Прибегайте к Enterprise ZK Mode, когда ваш исходный код нельзя читать. Если комплаенс запрещает предоставлять третьей стороне доступ на чтение репозитория, запускайте Action на собственных раннерах.
• Скажите команде, что это автоматически. Инженеры, которые считают проставление временных меток ручной задачей, в конце концов попытаются сделать это вручную — именно так появляются дублирующиеся или некорректные записи.

Вы можете начать с timestampgit.dev — установите приложение, подключите репозиторий и дайте первому ночному пакету выполниться.

FAQ

В: Нужно ли менять мой рабочий процесс Git, чтобы использовать автоматическое проставление временных меток? О: Нет. После установки GitHub App Timestamp GIT автоматически обнаруживает новые коммиты через вебхуки и проставляет им временные метки каждую ночь. Вы продолжаете коммитить как обычно — без дополнительных команд или шагов.

В: Что произойдёт, если я использую несколько веток или репозиториев? О: GitHub App отслеживает все ветки в репозиториях, к которым вы предоставили доступ. Вы также можете настроить, какие репозитории отслеживаются. Для нескольких репозиториев каждый получает собственный манифест и файлы доказательств.

В: Мой исходный код когда-либо раскрывается Timestamp GIT? О: Нет. В Standard Mode приложение читает только хеш HEAD-коммита — никогда ваш исходный код. В Enterprise ZK Mode GitHub Action на вашей инфраструктуре отправляет в наш API только хеш коммита, поэтому ваш код никогда не покидает вашу среду.

В: Сколько времени занимает проставление временной метки на коммит? О: Хеши коммитов пакетируются и привязываются к Bitcoin раз в ночь. После ночного запуска обычно требуется около 3 часов, чтобы транзакция Bitcoin подтвердилась, после чего файлы-доказательства .ots отправляются обратно в ваш репозиторий.

Заключение

Ручное проставление временных меток терпит неудачу по той же причине, по которой терпит неудачу весь ручной комплаенс: оно зависит от того, что человек помнит — каждый раз, всегда. GitHub App убирает эту зависимость. Установите его один раз, и каждый коммит во всех отслеживаемых репозиториях получает отпечаток, пакетируется, объединяется в корень Меркла и привязывается к Bitcoin по ночному расписанию — со значками, публичным дашбордом статуса, CSV-аудитом, PDF-сертификатами и локальной браузерной верификацией в качестве поддержки.

Если вы оцениваете это для команды, начните с одного приватного репозитория и посмотрите, как заполняется тепловая карта за первую неделю. Затем решите, насколько широко это развернуть.

Установите GitHub App, подключите свой первый репозиторий и позвольте ночному воркеру сделать остальное.

Похожие статьи

• Защита интеллектуальной собственности: руководство для разработчиков ПО
• Защита prior art для софтверных стартапов: руководство
• GitHub Action для проставления временных меток коммитов: руководство по настройке