Git, worktree и три платформы

Оглавление · Релизы и blue-green

Git хранит историю и ссылки на commit. GitHub, GitLab и SourceCraft добавляют обсуждение изменений, проверки, права и выпуск релизов. Worktree — отдельный каталог checkout; branch — отдельная изменяемая ссылка. Один worktree без своей ветки не изолирует интеграцию изменений.

Цикл одной задачи

Из чистой проверенной базы создайте свою ветку и worktree. Проверьте статус, общий Git directory и ignore вложенных checkout. Не переносите соседние изменения и неопубликованный main вместе со своей задачей.

git status --short --branch
git worktree list
git check-ignore .worktrees
git fetch sourcecraft main
git worktree add -b feat/example .worktrees/example sourcecraft/main
cd .worktrees/example

Сделайте небольшой этап, выполните проверки контракта и отдельный коммит. Публикация собственной ветки создаёт PR; CI и живой стенд проверяют её exact SHA. Перед merge сверяйте head, target SHA, обсуждения и завершившиеся проверки. После merge удаляется PR-стенд и отзываются сертификаты всех пяти адресов. Worktree удаляйте через git worktree remove, когда он чистый и больше не нужен.

Сопоставление терминов

Текущая доставка Gheilt — SourceCraft → YC Registry → исходящий VPS poll. GitHub Actions отключены и больше не участвуют в доставке. GitLab здесь не развёрнут. Его команды ниже — упражнения в отдельном sandbox, а не второй действующий production pipeline. Новые платные сервисы не нужны.

PR в SourceCraft

После push собственной ветки:

src pr create -R zakharov-dev/gheilt --base main --head feat/example \
  --title 'Добавить пример' --description 'Поведение и результат проверки'
python3 scripts/sourcecraft/changelog.py pr <номер> --dry-run
python3 scripts/sourcecraft/changelog.py pr <номер>
src pr checks <номер> -R zakharov-dev/gheilt --json

Changelog пишет только maintainer CLI из checkout того же head, для своего PR в собственном repository. Перед write заново проверяются target/head и description. Маркеры выделяют generated section; ручное объяснение и ограничения сохраняются. Дублированные или незакрытые маркеры останавливают обновление. CI не получает токен для записи description.

Release-ветка и её база

Main → test. Проверенную версию main выделяем в release/X.Y; она обновляет полный staging. Команда сохраняет исходный SHA ещё и в immutable release-base/X.Y: первый changelog получает явную воспроизводимую базу. Обе ссылки публикуются одним atomic Git push без force.

git fetch sourcecraft main
python3 scripts/sourcecraft/changelog.py branch --branch release/0.1 --dry-run
python3 scripts/sourcecraft/changelog.py branch --branch release/0.1

Команда использует актуальный SourceCraft main, а не локальный main с чужими неопубликованными коммитами. Если main переместился, выполните fetch и повторите. Release-ветка сохраняется для patch-релизов. Исправления делаются PR в неё; обратный перенос в main — отдельный PR с собственными проверками.

Notes, draft и выпуск

python3 scripts/sourcecraft/changelog.py release --branch release/0.1 \
  --version v0.1.0 --base-tag release-base/0.1 --dry-run
python3 scripts/sourcecraft/changelog.py release --branch release/0.1 \
  --version v0.1.0 --base-tag release-base/0.1
src release get v0.1.0 -R zakharov-dev/gheilt --json

Generate-notes API получает exact target SHA и предыдущий stable tag своей линии. Для первого релиза обязателен base tag. Тег предыдущего выпуска сверяется с native hash; диапазон должен быть доступен в локальной истории. Отсутствие объектов требует fetch, а не незаметного расширения диапазона. Команда создаёт draft и не публикует stable автоматически.

Публикация src release publish v0.1.0 -R zakharov-dev/gheilt — решение выпустить проверенную staging версию. Controller допускает только стабильный native Release, ту же ветку/SHA/четыре digest/receipt и совместимую CMS. Публикация ещё не означает успешное переключение production: проверьте applied receipt и живые адреса. Через release-cool охлаждается только выпущенное поколение staging; HTTP его будит.

Упражнения GitHub/GitLab

В отдельном учебном repository создайте PR через gh pr create или MR через glab mr create, задайте проверки branch/head и проверьте конфликт после перемещения target. Повторите выпуск immutable tag и draft release. Эти CLI не установлены и не настраиваются появлением главы: используйте официальные инструкции своей платформы и учебные данные.

Сравните, где хранятся CI configuration, secrets, approvals и artifacts. Объясните, почему зелёный check не доказывает live deployment, а runner с credentials не должен выполнять произвольный Dockerfile до удаления секретов.

AGENTS и технические ограничения

AGENTS.md и руководство закрепляют рабочую дисциплину: своя ветка, тесты, PR, changelog, свежий target и точный digest. Это не серверный запрет force push: человек с write-доступом может нарушить инструкцию. Branch protections добавляют техническое ограничение, но не являются обязательной зависимостью этого проекта. Runtime всё равно проверяет authority, SHA, ownership и migration contract.

Официальные материалы: SourceCraft CLI, GitHub CLI, GitLab CLI, SourceCraft release notes API.

SourceCraft с target_branch создаёт тег при публикации и отказывает, если он уже существует. Changelog CLI сначала закрепляет immutable Git tag на точном SHA, затем создаёт draft без target_branch: native API возвращает hash существующего тега. Публикация не перемещает tag, controller сверяет hash Release со staging. Если создание draft оборвалось после push тега, сохраните тег и создайте draft для него без target_branch; не удаляйте и не двигайте ref ради повтора.