СтатьиQlikИнструментыUI Kit Поиск RSS →
← Все статьи
скилыClaude CodeCursorAI skillsgitGitHubGitLabGitVersepull requestавтоматизацияИИЧернов пишет

Один домен, разные бэкенды: git-хостинги

Один домен, разные бэкенды: git-хостинги

Ты работаешь с несколькими git-хостингами сразу. Личное и опенсорс - на GitHub. Что-то рабочее - на GitLab. А теперь ещё и российский GitVerse, потому что так удобнее или так попросили. И каждый раз, когда нужно открыть запрос на слияние или выпустить релиз, ты переключаешь контекст в голове: где тут как.

Сам git везде один и тот же - ветки, коммиты, теги. А вот всё, что вокруг, разное. На GitHub запрос на слияние называется pull request, на GitLab - merge request. Команда там gh, тут glab, а на GitVerse готового CLI и вовсе нет - только REST. Токены свои у каждого. И ты держишь всю эту разницу в голове, лезешь в шпаргалки или открываешь веб-интерфейс и кликаешь руками.

Это ровно та рутина, которую пора отдать ассистенту. Приём простой: один домен - git, а бэкенды разные. То, что переносимо, делаем одинаково везде. То, что специфично, ассистент подставляет сам - по тому, куда смотрит твой репозиторий.

В чём идея

Скил - это не программа. Это короткая инструкция для ассистента: как называется, когда применять и что сделать. Ассистент читает её сам и, когда твоя просьба попадает под описание, подхватывает скил без напоминаний.

Главная мысль этого урока - разделить переносимое и специфичное. Переносимое - это сам git: создать ветку, закоммитить, запушить, повесить тег релиза. Эти операции одинаковы на GitHub, GitLab и GitVerse, потому что это и есть git, а не хостинг. Их скил делает обычным git, и они работают везде без единой правки.

Специфичное - это обвязка хостинга. Имя сущности (pull request против merge request), адрес API, способ доступа (CLI gh, CLI glab или прямой REST), свой токен. Вот это и есть единственное место, где хостинги расходятся. И именно здесь скил не зашивает один хостинг намертво, а определяет его по git remote origin: увидел github.com - значит GitHub и pull request; увидел gitlab (в т.ч. self-hosted GitLab по своему домену) - merge request; увидел gitverse.ru - REST на https://api.gitverse.ru.

Почему это работает? Потому что современная LLM прекрасно знает и git, и API каждого из этих хостингов. Ей не хватало одного - понятной инструкции с триггером и с чётким разделением: вот это делай одинаково, а вот тут смотри на origin и подставляй нужное. Скил ровно это и даёт. В итоге один и тот же приём ложится на три бэкенда, а ты пишешь одну и ту же фразу независимо от того, где сегодня лежит репозиторий.

И ещё важное: скил говорит, ЧТО сделать, а не ЧЕМ. Есть в системе gh или glab - ассистент возьмёт их, так короче. Нет - пойдёт через REST обычным запросом. Ты не диктуешь инструмент, ты описываешь результат.

Как себе сделать

Не пиши скил руками. Отдай задачу своему ассистенту - Claude Code, Codex, Cursor, Gemini, любому. Он сам разберётся, куда положить файл и как ходить в каждый хостинг. Просто скопируй промпт:

Создай мне скил для работы с репозиторием на любом git-хостинге - ветки, запрос на слияние, релизы.
Срабатывай на просьбы вроде "создай ветку", "открой PR или MR", "слей изменения", "выпусти релиз".
Хостинг определяй сам по git remote origin: github - это GitHub, gitlab (в т.ч. self-hosted GitLab по своему домену) - GitLab, gitverse.ru - GitVerse.
Раздели переносимое и специфичное. Переносимое (ветка, коммит, push, тег) делай обычным git - оно одинаково везде.
Специфичное делай через бэкенд хостинга: на GitLab это merge request, на GitHub и GitVerse - pull request; релиз создавай из тега.
Источник выбирай сам по тому, что доступно: CLI (gh или glab) либо REST соответствующего хостинга.
Токен бери из окружения нужного хостинга, не зашивай его в скил и не печатай в ответе.
В конце ответь одной строкой: что создано и ссылка на запрос слияния или релиз.

Как понять, что заработало: зайди в репозиторий на одном хостинге и попроси “открой PR из моей текущей ветки”, потом то же самое в репозитории на другом хостинге. Если ассистент сам определил, где он, подставил правильное имя сущности (где-то PR, где-то MR) и вернул рабочую ссылку - приём перенёсся, скил живой.

И всё. Один приём вместо трёх шпаргалок. Так же отделяется переносимое от специфичного в любой задаче, где у тебя один домен, но несколько разных бэкендов: суть делаешь одинаково, а различия отдаёшь ассистенту - пусть подставляет сам.

Смотреть полностью

Коротко