🚀 go-repo-orchestrator

Локальная TUI-утилита для оркестрации репозиториев, аудита задач и безопасной работы с Git-ветками

go-repo-orchestrator — это ваш персональный пульт управления хаосом в микросервисах. Инструмент решает проблемы долгого онбординга, позволяет проводить сквозной поиск по веткам, следить за реальными статусами задач из Jira и генерировать безопасные скрипты для удаления мусорных веток в интерактивном TUI.

Демонстрация работы приложения

📖 Оглавление

🔍 Проблема и Решение
✨ Скрытые фичи и возможности
🚀 Быстрый старт
💻 Установка
⌨️ Горячие клавиши
🏷️ Jira release-driven autocheck
⚙️ Конфигурация
📊 Сводный статус репозиториев (status)
⚡ Пакетный запуск команд (exec)
🔱 Поддержка форков и multi-remote (upstream)
🤝 Contributing

🔍 Проблема и Решение

При работе с десятками микросервисов разработчик тратит кучу времени на рутину: долгий онбординг, сложные переключения (cd) между папками, потерю контекста статусов из таск-трекера и страх случайно удалить нужную ветку командой git branch -D.

go-repo-orchestrator решает эти боли, объединяя управление всеми репозиториями в одном интерфейсе.

Боль	❌ Обычный подход	✅ go-repo-orchestrator
Долгий онбординг	Ручное клонирование 50+ репо по папкам	Запуск с общим `config.yaml` автоматически вытягивает и раскладывает все проекты
Поиск и навигация	Бесконечные `cd`, `git branch`, IDE	Глобальный поиск веток и переход (Checkout) кликом мыши или нажатием `Enter`
Зависающие задачи	Искать статусы вручную	Сквозной мониторинг статусов из Jira напрямую в TUI (легко найти отмененные задачи)
Смена Jira/Проектов	Неудобно отслеживать разные домены	Поддержка одновременной работы сразу с несколькими инстансами Jira
Опасность `git branch -D`	Страх удалить чужой код / production	TUI-выбор с предпросмотром, генерацией скрипта и `branch.keep` regex защитой

🔒 Безопасное удаление по умолчанию

Деструктивные команды не выполняются "под капотом". Вы выбираете ветки в TUI, после чего генерируется .sh / .bat скрипт, который вы сможете проанализировать и запустить вручную. К тому же, утилита аппаратно защищает текущую активную ветку и системные ветки (по умолчанию: main|master|prod|release).

Принципы безопасности:

Assistive-only: Инструмент только помогает найти кандидатов на удаление, но никогда не принимает окончательное решение сам.
Никакого Auto-delete: Автоматическое удаление веток отсутствует как класс.
Приоритет ручного выбора: Любая автоматическая пометка (regex или Jira autocheck) может быть мгновенно отменена пользователем в TUI.
Никакого Silent Auto-run: Проверки статусов релизов никогда не запускаются скрытно при старте или обновлении (refresh) — только по явному действию пользователя.

✨ Скрытые фичи и возможности

🚀 Мгновенный онбординг (Workspace-менеджер): Поделитесь одним YAML-файлом конфигурации с командой. При запуске оркестратор сам склонирует все недостающие репозитории и разложит их по правильным директориям, экономя часы новичкам.
👁️ Глубокая интеграция с Jira:
- Оркестратор мониторит не только факт того, что ветка слита, но и реальные статусы задач.
- Вы сразу поймете, что задача висит "В ревью", даже если Merge Request ещё никто не открыл.
- Мгновенное выявление заброшенных или отмененных из-за смены приоритетов задач для очистки локального мусора.
- Multi-Jira: Работа с несколькими Jira-инстансами одновременно (идеально для ситуаций, когда часть проектов "переезжает" на новые сервера).
🔀 Удобная навигация и Checkout: Смена активных веток одним нажатием Enter. Вам больше не нужно "прыгать" через терминалы и IDE по папкам.
🔎 Сквозной поиск: Глобальный поиск нужных веток и репозиториев прямо из TUI. Незаменимая фича, когда в рамках одной задачи вы модифицируете 5-7 разных репозиториев.
🗑️ Генерация команд очистки: Формирует пачки git branch -D для локальных веток и git push <remote> --delete для удаленных с учетом строгих правил безопасности.
🏷️ Jira release-driven autocheck:
- По нажатию * во вкладке веток можно запустить автоматическую пометку кандидатов на удаление на основе статуса релиза в Jira.
- Оркестратор предложит выбрать один из недавно выпущенных (Released) релизов, найдет все связанные с ним задачи и пометит соответствующие локальные ветки.
- Assistive-only: Автоматика только предлагает выбор, окончательное решение всегда за пользователем (Manual override > Auto-mark).
- Session-only: Выбор релиза сохраняется только в рамках текущей сессии.
- Resilience (release-autocheck only): В рамках Jira release-driven autocheck поддерживается bounded retry/backoff и заголовок Retry-After для обхода лимитов Jira API.
- No Silent Auto-run: Проверка никогда не запускается автоматически при старте или обновлении.
🌐 CDP & Playwright-мосты: Дополнительный транспорт через Chromium для сложных Jira-групп с защитой (Cloudflare/Captchas).

🚀 Быстрый старт

Требования:

Go 1.24+
Установленный git в $PATH

Существует два основных сценария работы с конфигурацией оркестратора:

Сценарий 1: С готовым конфингом (Онбординг)

Идеально, если в вашей команде уже есть подготовленный файл конфигурации. Оркестратор автоматически скачает (через git clone) недостающие репозитории по URL в нужную структуру.

# 1. Скачиваем конфигурацию (в качестве примера возьмем базовый шаблон)
curl -O https://raw.githubusercontent.com/AgelxNash/go-repo-orchestrator/main/config.example.yaml

# 2. Запускаем оркестратор
go run ./cmd/go-repo-orchestrator --config config.example.yaml

Сценарий 2: Генерация конфига из существующих репозиториев (инвентаризация)

Если у вас уже есть директория с Git-репозиториями, команда generate рекурсивно просканирует её, найдет все репозитории (по наличию .git) и сформирует первичный конфиг из реально найденных рабочих копий: имя, URL origin (если доступен) и абсолютный путь. Это снимок вашей текущей структуры, а не чистый шаблон со всеми настройками:

# 1. Инвентаризируем текущую директорию: все вложенные git-репозитории попадут в конфиг
go run ./cmd/go-repo-orchestrator generate --config ./my-repo.gbc.yaml

# 2. Отредактируйте my-repo.gbc.yaml. Команда заполняет только repos[].name/url/path —
#    секцию jira, browser и правила branch.keep / branch.jira / branch.autocheck
#    нужно добавить вручную под свой workflow.

# 3. Запускаем оркестратор
go run ./cmd/go-repo-orchestrator --config ./my-repo.gbc.yaml

Если нужен образец конфигурации со всеми секциями и демонстрационными значениями — возьмите статический файл config.example.yaml из сценария 1 и адаптируйте его под себя.

Для просмотра полной справки по CLI:

go run ./cmd/go-repo-orchestrator --help

💻 Установка

Из исходников:

make build
./bin/go-repo-orchestrator --config ./config.example.yaml

Через go install:

go install github.com/agelxnash/go-repo-orchestrator/cmd/go-repo-orchestrator@latest

Для скачивания готовых бинарных файлов посетите раздел GitHub Releases.

⌨️ Горячие клавиши

Основные

F2 — Показать/скрыть нижнюю панель информации.
F3 — Поиск (Глобально по веткам и проектам).
F4 — Область веток (Локальные → Удаленные → Все).
F5 (или r) — Обновить контекст текущей вкладки.
F6 — Сортировка.
F8 (или g) — Генерация скрипта.
F10 (или q / Ctrl+C) — Выход из приложения.

Вкладка «Репозитории»

Enter: Открыть ветки для активного репозитория.
F7: Выполнить fetch + pull для активного репозитория.

Вкладка «Ветки»

Enter: Сделать checkout на выбранную ветку без необходимости открывать терминал.
Пробел / Insert: Отметить ветку для скрипта удаления.
F7: Создать локальную tracking-копию удаленной ветки (если репозиторий не в режиме url-only).
F9: Скрыть/показать защищенные ветки.
*: Запуск Jira release-driven autocheck.
+: Инверсия выбора веток (выбрать все невыбранные, снять выбор с выбранных).

🏷️ Jira release-driven autocheck

Функция позволяет быстро найти и пометить ветки, связанные с задачами, которые уже вошли в конкретный релиз Jira.

Процесс работы:

Нажмите * во вкладке веток.
Оркестратор загрузит список последних релизов (Released) из Jira.
Выберите нужный релиз в модальном окне.
Инструмент найдет все задачи в статусе "Done", привязанные к этому релизу.
Используя механизм branch.jira matching, оркестратор автоматически пометит соответствующие локальные ветки как кандидатов на удаление.

Гарантии и ограничения:

Assistive-only: Это лишь подсказка. Вы всегда можете снять пометку вручную перед генерацией скрипта.
No Auto-delete: Ветки не удаляются автоматически, только помечаются для включения в скрипт.
No Silent Auto-run: Запросы к Jira API для проверки релизов выполняются только по явному нажатию *.
Session-only: Выбранный релиз и результаты проверки хранятся только до закрытия приложения.
Resilience: При получении ошибки 429 (Too Many Requests) оркестратор использует стратегию bounded retry/backoff с учетом заголовка Retry-After. Вы можете прервать ожидание в любой момент.

⚙️ Конфигурация

Статический демонстрационный пример со всеми секциями находится в файле config.example.yaml — это готовый файл в репозитории, его можно скачать и адаптировать (см. Быстрый старт, сценарий 1). Не путайте его с командой generate: она выполняет инвентаризацию текущей директории и включает в конфиг только найденные Git-репозитории (repos[].name/url/path), а остальные секции (jira, browser, branch.*-правила) добавляются вручную. Обязательным требованием является передача файла конфигурации через флаг --config.

Ключевые секции конфига:

repos[].name, repos[].url, repos[].path — базовые настройки репозитория (поддержка url, path, url+path).
repos[].branch.keep — regex-выражение для системных/защищенных веток.
repos[].branch.jira — regex-выражение для извлечения Jira ключа (например, [A-Z]+-\d+).
jira[] — настройки интеграции с Jira:
- group — группа/проект в Jira (например, "MYPROJ").
- url — базовый URL Jira (например, "https://company.atlassian.net").
- playwright — булево: true включает браузерный транспорт через CDP/Chromium; false (по умолчанию) использует HTTP-транспорт.
- token — API-токен для Bearer-аутентификации (если указан, добавляется заголовок Authorization: Bearer <token>).
- login.username / login.password — учетные данные для Basic Auth (используются, если оба поля заданы и token пуст).
- type — вспомогательное поле конфигурации, не влияющее на runtime-логику (может быть использовано для документирования или будущих расширений).
browser.cdp_url — URL для подключения к уже запущенному Chromium через CDP (например, "http://127.0.0.1:9222"). Используется при playwright: true. Поддерживаются только loopback-адреса (127.0.0.1, [::1]).

Связь Jira-групп с ветками

Оркестратор поддерживает несколько Jira-инстансов одновременно. Чтобы определить, к какой Jira-группе относится та или иная ветка, используется механизм named capture groups в regex из repos[].branch.jira. Этот же механизм используется для автоматического сопоставления веток с задачами при выполнении Jira release-driven autocheck.

Как это работает:

jira[].group — идентификатор Jira-группы/инстанса (например, "MARIADB", "SIMPLEWINE").
В regex для branch.jira можно определить named-group, имя которого совпадает с jira.group. Когда ключ тикета извлекается из имени ветки, оркестратор находит соответствующую Jira-группу по имени named-group.
Если в regex используется универсальное имя (?P<JIRA>...), ключ тикета будет искаться во всех настроенных Jira-группах (fallback-вариант).

Примеры:

# Прямой mapping: named-group "SIMPLEWINE" -> jira.group: "SIMPLEWINE"
jira:
  - group: "SIMPLEWINE"
    url: "https://simplewine.atlassian.net"
    token: "..."
repos:
  - name: "My Service"
    path: ./services/my-service
    branch:
      jira:
        - '(?P<SIMPLEWINE>SW-\d+)'  # Ключ "SW-123" найдет группу SIMPLEWINE

# Fallback: универсальный named-group "JIRA" работает с любой группой
jira:
  - group: "PROJ-A"
    url: "https://proj-a.atlassian.net"
  - group: "PROJ-B"
    url: "https://proj-b.atlassian.net"
repos:
  - name: "Shared Lib"
    path: ./libs/shared
    branch:
      jira:
        - '(?P<JIRA>[A-Z]+-\d+)'  # Ключ "PROJ-123" проверит обе группы

Почему generate не заполняет эти поля автоматически:

Команда generate сканирует текущую директорию и записывает в конфиг только найденные Git-репозитории (имя, URL origin, путь). Она не может угадать:

Какие Jira-инстансы использует ваша команда (URL, токены, групповые имена).
Как именно вы именуете ветки (префиксы, разделители, форматы ключей).
Какие named-group имена предпочтительны для вашего случая.

Эти параметры требуют ручной настройки под конкретную организацию и workflow.

Можно переопределять конфигурацию через переменные окружения с префиксом GBC_ (например, GBC_STATE_DIR).

Переменные окружения в значениях конфига

Во всех строковых значениях YAML поддержаны плейсхолдеры в синтаксисе docker-compose:

jira:
  - group: "MYPROJ"
    url: "https://jira.corp.local"
    token: ${MYPROJ_JIRA_TOKEN}              # обязательная переменная
    login:
      username: ${MYPROJ_JIRA_USER:-}        # пустой дефолт — поле необязательное
    ssl:
      client_cert: ${MYPROJ_CERT:-/etc/ssl/corp/jira-client.pem}
browser:
  cdp_url: ${GRO_CDP_URL:-http://127.0.0.1:9222}

Правила:

${VAR} — подставляется значение переменной; если переменная не задана, старт завершается понятной ошибкой (имя переменной + путь ключа), а не тихой подстановкой пустой строки.
${VAR:-default} — значение по умолчанию, если переменная не задана или пустая; ${VAR:-} легализует необязательное поле.
Имена переменных произвольные — они задаются прямо в YAML, утилита их не зашивает.
Литеральный $ экранируется как $$ — актуально для regex-правил branch.keep/branch.jira, где одиночный $ (якорь конца строки) и так не трогается.
Поддерживается только подстановка и дефолт — это не шаблонизатор с условной логикой.

Такой конфиг можно коммитить в репозиторий команды: структура, пути и regex-правила общие, а токены, пароли и пути к сертификатам каждый участник держит в своём окружении.

Для editor-autocomplete и ранней проверки структуры используйте JSON Schema: config.schema.json. Runtime-загрузчик также работает в strict-режиме: неизвестные YAML-ключи считаются ошибкой конфигурации, чтобы опечатки не игнорировались молча.

Авторизация Jira

Интеграция с Jira поддерживает два транспортных режима, управляемых полем playwright:

Browser transport (playwright: true) — для SSO/сложных сценариев с Cloudflare/Captchas. Пользователь авторизуется вручную в открываемом браузере/Chromium. После истечения SSO-сессии требуется повторный вход. Рекомендуется использовать browser.cdp_url для подключения к уже запущенному CDP-сеансу.
HTTP transport (playwright: false или отсутствие поля) — стандартные HTTP-запросы к Jira REST API.

Для аутентификации в HTTP-режиме используются:

Bearer auth — если задано поле token, добавляется заголовок Authorization: Bearer <token> (для Jira Server/DC это Personal Access Token).
Basic auth — если заданы login.username и login.password (и token пуст), используется базовая аутентификация.

mTLS и корпоративные CA (опциональный блок ssl): для Jira Server/DC за mutual TLS или self-signed-прокси каждой группе можно задать клиентский сертификат и доверенный CA:

jira:
  - group: "MYPROJ"
    url: "https://jira.corp.local"
    token: "..."                # PAT (Bearer) — комбинируется с mTLS
    ssl:
      client_cert: /etc/ssl/corp/jira-client.pem  # combined PEM (cert+key) или только сертификат
      # client_key: /etc/ssl/corp/jira.key        # отдельный файл ключа (если не combined)
      # client_key_password: "..."                # для традиционно зашифрованного PEM-ключа
      # ca_cert: /etc/ssl/corp/root-ca.pem        # корпоративный CA вместо системного trust store
      # verify: false                             # только для тестовых сред (по умолчанию true)

Сертификат участвует в TLS-handshake, а token/login — в HTTP-заголовках: любые комбинации разрешены. Ошибки загрузки сертификатов приводят к остановке приложения на старте с понятным сообщением. Browser transport (playwright: true) использует сертификаты системного хранилища браузера и блоком ssl не управляется.

Для запросов в рамках Jira release-driven autocheck оркестратор поддерживает стратегию bounded retry/backoff и корректно обрабатывает заголовок Retry-After при получении ошибки 429 (Too Many Requests).

Поле type является вспомогательным и не влияет на runtime-логику (может использоваться для документирования).

Fallback и подсказки: При недоступном browser runtime (например, отсутствует Chromium) для групп с playwright: true приложение автоматически делает HTTP fallback. Если для Jira требуется авторизация через браузер, TUI покажет соответствующую подсказку с инструкцией.

Примеры конфигурации

SSO/Playwright (с CDP):

jira:
  - group: "MYPROJ"
    url: "https://company.atlassian.net"
    playwright: true

browser:
  cdp_url: "http://127.0.0.1:9222"

HTTP с Bearer-токеном:

jira:
  - group: "MYPROJ"
    url: "https://company.atlassian.net"
    token: "your_api_token_here"

HTTP с Basic Auth:

jira:
  - group: "MYPROJ"
    url: "https://company.atlassian.net"
    login:
      username: "user@example.com"
      password: "secret"

Как запустить браузер с CDP

При использовании playwright: true оркестратор подключается к уже запущенному браузеру через CDP. Запустите Chromium/Chrome в отдельном сеансе с включённым remote debugging:

Linux/macOS:

# Создаём отдельный профиль, чтобы не мешать основному браузеру
PROFILE_DIR="$HOME/.config/go-repo-orchestrator-chrome-profile"

# Запускаем Chrome/Chromium с CDP
google-chrome \
  --remote-debugging-port=9222 \
  --remote-debugging-address=127.0.0.1 \
  --user-data-dir="$PROFILE_DIR" \
  --no-first-run \
  --no-default-browser-check \
  "https://company.atlassian.net" &

Или для chromium:

chromium-browser \
  --remote-debugging-port=9222 \
  --remote-debugging-address=127.0.0.1 \
  --user-data-dir="$HOME/.config/go-repo-orchestrator-chrome-profile" \
  --no-first-run \
  --no-default-browser-check \
  "https://company.atlassian.net" &

Windows (PowerShell):

# Отдельный профиль
$env:PROFILE_DIR = "$env:APPDATA\go-repo-orchestrator-chrome-profile"

# Запуск Chrome (путь может отличаться в зависимости от системы)
& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --remote-debugging-port=9222 `
  --remote-debugging-address=127.0.0.1 `
  --user-data-dir="$env:PROFILE_DIR" `
  --no-first-run `
  --no-default-browser-check `
  "https://company.atlassian.net"

Зачем отдельный --user-data-dir: чтобы запущенный для CDP браузер не конфликтовал с вашим основным профилем Chrome/Chromium (расширения, история, куки). После завершения работы с оркестратором можно безопасно удалить эту папку.

Убедитесь, что browser.cdp_url в конфиге указывает на http://127.0.0.1:9222.

Диагностика: `doctor`

Команда doctor позволяет изолированно отладить интеграции и загрузку репозиториев без запуска TUI:

Диагностика Jira: `doctor jira`

Если статусы задач показываются как auth [A] и непонятно почему — выполните один диагностический запрос с полным трейсом:

go-repo-orchestrator doctor jira PROJ-123 --config config.yaml

Команда определяет jira-группу по ключу задачи (named-group mapping из repos[].branch.jira; если ключ не замаплен — проверяет все группы), выполняет ровно один запрос тем же транспортным кодом, что и TUI, и печатает: группу, base URL, транспорт, тип авторизации (только факт, без секретов), итоговый URL, HTTP-статус, content-type, final URL, размер и санитизированный фрагмент тела (до 512 байт), вердикт классификатора auth (401 / 403 / login-redirect / HTML-ответ), а для browser-групп — результат CDP preflight, режим подключения и выбор контекста (сколько их, у скольких есть куки для домена, какой будет использован), включая факт и причину browser→HTTP fallback.

При недоступном браузере/CDP команда завершается ненулевым кодом; вывод можно перенаправить в файл и приложить к багрепорту.

Диагностика репозиториев: `doctor repo`

Если репозиторий в интерфейсе показывает «Ошибка доступа к репозиторию» или «Веток: 0» — выполните диагностику загрузки конкретного репозитория:

go-repo-orchestrator doctor repo group/repo --config config.yaml

Команда печатает: source-тип (path / url / opensource), URL (с маскированием учетных данных), абсолютный и относительный путь к каталогу репозитория, состояние каталога и Git (валидность HEAD, текущая ветка, количество локальных и remote-веток, upstream, незакоммиченные изменения), предупреждение об autoswitch (применение reset --hard и clean -fd), пробу синхронизации fetch --prune origin с полной ошибкой и понятный вердикт: «репозиторий загрузится» / «не тот каталог» / «клон-обрывок без коммитов» / «каталог не существует».

Только loopback-эндпоинты: browser.cdp_url принимает исключительно loopback IP (127.0.0.1, [::1]) — имя localhost и внешние адреса отклоняются валидацией конфига. Preflight дополнительно проверяет, что webSocketDebuggerUrl из ответа /json/version указывает на loopback и использует схему ws/wss; проваленная проверка блокирует подключение. Это защищает от подключения к посторонним debug-эндпоинтам.

📊 Сводный статус репозиториев (`status`)

Команда status позволяет быстро получить сводную информацию о состоянии всех отслеживаемых репозиториев без запуска TUI:

go-repo-orchestrator status --config config.yaml

Команда параллельно (до 8 воркеров) опрашивает репозитории из конфигурации и выводит сводную таблицу:

РЕПОЗИТОРИЙ          ВЕТКА    СОСТОЯНИЕ      СИНХРОНИЗАЦИЯ  ОШИБКА
group/backend        main     чистый         -              -
group/frontend       feature  с изменениями  -              -

Всего: 2 | Чистых: 1 | С изменениями: 1 | Ошибок: 0

Флаги команды `status`:

--json — вывод отчета в формате JSON (удобно для CI/CD и скриптов автоматизации).
--filter <all|dirty|clean|error> (по умолчанию: all) — фильтрация репозиториев в отчете:
- all — все репозитории;
- dirty — только репозитории с незакоммиченными изменениями;
- clean — только чистые репозитории;
- error — только сбойные репозитории с ошибкой доступа/загрузки.
--ignore-errors — не завершать команду с ненулевым кодом выхода при наличии сбойных репозиториев (по умолчанию при наличии хотя бы одной ошибки команда завершается с кодом ошибки после гарантированного вывода отчета в stdout).

Примеры использования:

# Табличный вывод только измененных репозиториев
go-repo-orchestrator status --filter dirty --config config.yaml

# Экспорт полного отчета в JSON для автоматизации
go-repo-orchestrator status --json --config config.yaml

# Проверка без падения при сетевых сбоях отдельных репозиториев
go-repo-orchestrator status --ignore-errors --config config.yaml

⚡ Пакетный запуск команд (`exec`)

Команда exec позволяет параллельно запускать произвольные команды и скрипты по всем сконфигурированным репозиториям:

go-repo-orchestrator exec --config config.yaml -- git status -s

Команда выполняется напрямую без промежуточной shell-интерполяции (защита от инъекций), с принудительно отключенным stdin (защита от зависания интерактивных утилит) и буферизацией вывода блоками с префиксом [repo-name].

Флаги команды `exec`:

--parallel <N> (по умолчанию: 4) — количество параллельных воркеров.
--filter <regex> — фильтрация репозиториев по регулярному выражению имени.
--timeout <duration> (по умолчанию: 60s) — общий таймаут выполнения для каждого репозитория.
--fail-fast — немедленная отмена оставшихся задач при падении хотя бы одного репозитория.
--json — структурированный машиночитаемый JSON-отчет в stdout со временем выполнения duration_ms, кодами возврата и потоками stdout/stderr.

Примеры использования:

# Проверка чистоты git-статуса во всех репозиториях
go-repo-orchestrator exec --config config.yaml -- git status -s

# Запуск тестов только в репозиториях, оканчивающихся на 3
go-repo-orchestrator exec --config config.yaml --filter ".*3$" -- make test

# Машинный JSON-отчет для CI/CD и AI-агентов
go-repo-orchestrator exec --config config.yaml --json -- php -v

🔱 Поддержка форков и multi-remote (`upstream`)

Оркестратор поддерживает Forking Workflow и работу с несколькими remotes:

repos:
  - name: "MiniShop3"
    path: "./revo/MiniShop3"
    url: "git@github.com:AgelxNash/MiniShop3.git"       # Личный форк (origin)
    upstream: "git@github.com:modx-pro/MiniShop3.git"   # Официальный репозиторий (upstream)

Возможности:

При подготовке каталога оркестратор автоматически гарантирует наличие remote upstream и соответствие его адреса.
При синхронизации (F7 в TUI или FetchAndPull) выполняется параллельный fetch для origin и upstream.
Во вкладке «Ветки» при переключении области на «Удаленные» или «Все» отображаются ветки обоих remotes (origin/* и upstream/*), что позволяет создавать от них локальные tracking-копии клавишей F7.
Команда doctor repo выводит статус подключения и пробу синхронизации для обоих remotes.

Каталог состояния

Утилита хранит свое состояние (и выкачанные workspace-репозитории) в:

Linux/macOS: $HOME/.local/state/go-repo-orchestrator
Fallback: .go-repo-orchestrator-state

Клонированные workspace хранятся по пути: <state-dir>/workspace/<repo-name>__<url-hash>/.

О генерации скриптов очистки

Генерируемые .sh/.bat создаются в вашей текущей рабочей директории терминала в формате:

go-repo-orchestrator-<repo>-delete-<session>-<timestamp>.sh

Важно понимать, что механизмы автоматической пометки (regex-autocheck и Jira release-driven autocheck) только формируют предварительный выбор кандидатов в TUI. Окончательное решение об удалении всегда остается за пользователем при запуске сгенерированного скрипта.

🤝 Contributing

Будем рады вашему вкладу! Для ознакомления с правилами Conventional Commits, требованиями к Pull Requests и обязательными проверками, пожалуйста, прочитайте CONTRIBUTING.md.

🛠️ Подготовка окружения (Onboarding)

Быстрый onboarding перед первым коммитом:

make commitlint-install
make golangci-lint-install
make setup-hooks

Команды установят необходимые утилиты (commitlint, golangci-lint) и пропишут настройки core.hooksPath=.githooks для локальных quality gates (pre-commit и pre-push).

Быстрые локальные проверки (manual call):

make fmt-check
make vet
make check

📦 Информация о релизах (Для Maintainers)

Релизный workflow находится в .github/workflows/release.yaml.

Триггер: push тега с префиксом v*.
Используется GoReleaser + GPG signing checksum-файла.

Проверка подписи скачанных артефактов в релизе:

gpg --verify checksums.txt.sig checksums.txt
sha256sum -c checksums.txt

📈 Roadmap

Введение полноценного i18n-слоя для CLI/TUI и пользовательских сообщений.
Потенциальная опция автооткрытия IDE (VS Code / JetBrains) для выбранного репозитория и/или ветки из интерфейса.

⭐ Star History

👥 Contributors

Made with contrib.rocks.

📄 License

Name		Name	Last commit message	Last commit date
.githooks		.githooks
.github		.github
ai-context		ai-context
cmd/go-repo-orchestrator		cmd/go-repo-orchestrator
internal		internal
scripts		scripts
.commitlint.yml		.commitlint.yml
.gitignore		.gitignore
.golangci.yml		.golangci.yml
.goreleaser.yaml		.goreleaser.yaml
.yamllint		.yamllint
CHANGELOG.md		CHANGELOG.md
CODE_OF_CONDUCT.MD		CODE_OF_CONDUCT.MD
CONTRIBUTING.md		CONTRIBUTING.md
LICENSE		LICENSE
Makefile		Makefile
README.md		README.md
SECURITY.md		SECURITY.md
commitlint.config.mjs		commitlint.config.mjs
config.example.yaml		config.example.yaml
config.schema.json		config.schema.json
go.mod		go.mod
go.sum		go.sum

Latest commit

History

Folders and files

Repository files navigation

🚀 go-repo-orchestrator

📖 Оглавление

🔍 Проблема и Решение

🔒 Безопасное удаление по умолчанию

✨ Скрытые фичи и возможности

🚀 Быстрый старт

Сценарий 1: С готовым конфингом (Онбординг)

Сценарий 2: Генерация конфига из существующих репозиториев (инвентаризация)

💻 Установка

⌨️ Горячие клавиши

Основные

Вкладка «Репозитории»

Вкладка «Ветки»

🏷️ Jira release-driven autocheck

⚙️ Конфигурация

Связь Jira-групп с ветками

Переменные окружения в значениях конфига

Авторизация Jira

Примеры конфигурации

Как запустить браузер с CDP

Диагностика: doctor

Диагностика Jira: doctor jira

Диагностика репозиториев: doctor repo

📊 Сводный статус репозиториев (status)

Флаги команды status:

Примеры использования:

⚡ Пакетный запуск команд (exec)

Флаги команды exec:

Примеры использования:

🔱 Поддержка форков и multi-remote (upstream)

Каталог состояния

О генерации скриптов очистки

🤝 Contributing

📈 Roadmap

⭐ Star History

👥 Contributors

📄 License

About

Topics

Resources

Contributing

Security policy

Stars

Watchers

Forks

Releases

Sponsor this project

Packages

Used by

Contributors

Languages

Диагностика: `doctor`

Диагностика Jira: `doctor jira`

Диагностика репозиториев: `doctor repo`

📊 Сводный статус репозиториев (`status`)

Флаги команды `status`:

⚡ Пакетный запуск команд (`exec`)

Флаги команды `exec`:

🔱 Поддержка форков и multi-remote (`upstream`)