Forge - единый CLI для любого git-forge

Третья заметка Несбитта в вики. Паттерн повторяется: он находит слой open-source-инфраструктуры, где каждая экосистема независимо реализовала одно и то же несовместимыми способами, и строит поверх слой нормализации. Libraries.io и ecosyste.ms сделали это для реестров пакетов. git-pkgs сделал это для lock-файлов. Forge делает это для git-хостингов.

Фрагментация

У каждого forge свой CLI. gh для GitHub, glab для GitLab, tea для Gitea/Forgejo, несколько вариантов для Bitbucket. Все они делают примерно одно и то же - открывают PR, выводят списки issue, собирают релизы, управляют секретами - и все расходятся в синтаксисе. Разные деревья подкоманд, разные соглашения по флагам, разные ментальные модели того, какие эндпоинты API получают отдельную команду, а какие прячутся в универсальной команде api.

В итоге возникает налог на удобство, растущий с каждым новым forge в работе. Тот, кто разрывается между двумя хостингами, платит его постоянно; тот, кто сидит только на GitHub, даже не подозревает о его существовании.

Что такое Forge

Единый CLI и библиотека на Go, которые автоматически определяют forge по текущему git remote и отправляют нужные вызовы API через согласованный интерфейс команд:

forge repo view
forge issue list --state open
forge pr create --title "Fix bug" --head fix-branch
forge release list

Покрытие примерно то же, что и у gh: репозитории, issue, PR, релизы, ветки, CI-пайплайны, метки, майлстоуны, deploy key, секреты, комментарии. Self-hosted-экземпляры распознаются по URL remote'а наравне с облачными.

Аутентификация повторно использует уже имеющиеся данные: она читает токены gh и glab из их стандартных мест, а также принимает флаги, переменные окружения или конфиг-файл. Так что если у вас уже выполнен gh auth login и экспортирован персональный токен доступа GitLab, Forge заработает из коробки.

В роли библиотеки

CLI - это только половина. Вторая половина - импортируемый модуль на Go с тем же согласованным API. Программе, использующей Forge, не нужны условные переходы под каждого провайдера, достаточно единого интерфейса с подключаемыми бэкендами.

И это более ценный и долговечный вклад. CLI - инструмент личной продуктивности; библиотека - инфраструктура для любых будущих инструментов, которым нужна независимость от forge без необходимости заново изобретать абстракцию.

Перспектива для ИИ-агентов

Любопытный тезис на будущее: большинство современных кодинг-агентов жестко завязаны на API GitHub. Когда проект пользователя лежит на GitLab, Gitea или self-hosted Forgejo, агент либо вовсе игнорирует forge, либо откатывается к вызовам git через командную строку, теряя доступ к PR, issue и CI. В формулировке Несбитта слой абстракции вроде Forge "упрощает код агента и делает выбор forge менее жестким ограничением".

Тот же ход, что и в alternative-frontend-pattern, но в обратном направлении: вместо фронтенда, умеющего работать только со структурой данных одного бэкенда, клиент, работающий со множеством бэкендов через единый формат.

Ограничения

• Библиотека только на Go. Если ваш фреймворк для агентов написан на TypeScript или Python, остаётся только CLI без модуля.
• Нормализация работает только потому, что поддерживаемые forge сошлись на одинаковой объектной модели. tools-matter - пример, ломающий этот подход: forge, переосмысливающий контроль доступа и хранящий issue в виде файлов внутри репозитория, не имеет привычных для GitHub объектов для сопоставления.
• Набор поддерживаемых forge ограничен: sourcehut, Codeberg помимо стандартного Forgejo, коммерческие системы вроде Bitbucket Data Center и другие не поддерживаются. При этом выбор forge для проекта важен не только из-за инструментов: httpx2-blessed-fork - случай, когда форк на Codeberg уступил форку на GitHub отчасти просто из-за находимости.
• Как и с любым слоем нормализации, пересечение возможностей разных forge оказывается уже набора функций каждого отдельного сервиса. Forge даёт общий знаменатель, а не полную функциональность каждого forge.

Значимость

Для разработчика, совмещающего несколько forge (например, GitHub по работе и другой хостинг для личных проектов), Forge - вполне разумная замена изучению двух-трёх разных CLI. Для авторов агентов это инфраструктура, за которой стоит следить, - точно так же, как Libraries.io стал ключевым звеном для анализа цепочек поставок, когда подход "давайте просто распарсим package.json" перестал масштабироваться.

Связанные страницы

• nesbitt-io - страница блога; третья обработанная статья
• features-to-steal-from-npmx - предыдущая заметка Несбитта, также об альтернативных фронтендах поверх устоявшейся инфраструктуры
• git-magic-files - предыдущая заметка Несбитта о том, что сам git отслеживает на уровне репозитория
• alternative-frontend-pattern - смежная концепция, обратное направление
• forge - сам инструмент