Работа с Git и репозиториями PrimeAI

Проект PrimeAI организован как несколько отдельных Git‑репозиториев, размещённых в одном дереве каталогов. MCP‑сервер, Telegram‑бот, SIP Hook и документация живут в собственных папках (mcp-server/, telegram-bot/, sip-hook/, primeai-docs/), каждая из которых содержит свою директорию .git, историю коммитов и набор веток.

Это важно учитывать при работе из командной строки и IDE: команды git status, git commit, git push и любые операции с ветками нужно выполнять внутри нужного репозитория (нужного сервиса или primeai-docs/), а не из корня PrimeAI/. В одном каталоге лежат несколько независимых репозиториев.

Если вы поднимаете всю систему локально с нуля, обычно сначала создаётся общий каталог, затем в него клонируются репозитории сервисов и документации. Например:

mkdir PrimeAI
cd PrimeAI

git clone <URL_MCP_SERVER> mcp-server
git clone <URL_TELEGRAM_BOT> telegram-bot
git clone <URL_SIP_HOOK> sip-hook
git clone <URL_PRIMEAI_DOCS> primeai-docs

Конкретные URL зависят от вашей инфраструктуры (GitHub, GitLab, внутренний Git‑сервер). После клонирования в каждом из сервисов можно работать независимо: запускать тесты, менять код, собирать Docker‑образы и т. д.

Обычно рабочий процесс такой: обновляете основную ветку в нужном сервисе (обычно main или master), создаёте ветку под задачу, вносите изменения и делаете коммиты с осмысленными сообщениями. Когда закончили — пушите ветку и открываете Pull Request / Merge Request.

Если задача про один сервис — работаем в одном репозитории. Если правки затрагивают несколько частей системы (например, добавили MCP‑инструмент в mcp-server и используем его в Telegram‑боте и SIP Hook), чаще всего удобнее идти так: сначала обновить MCP‑сервер (доменная логика, инструменты, документация к ним), потом — клиентов, которые этот инструмент вызывают. На каждый сервис заводим отдельную ветку и отдельный PR, даже если это одна бизнес‑фича.

Документация хранится в отдельном репозитории primeai-docs/, поэтому правки документации коммитятся и публикуются отдельно от правок сервисов. Меняете контракты MCP‑инструментов, схему БД или поведение клиентов — обновите соответствующие разделы документации в той же задаче.

Коммиты лучше держать небольшими и цельными, а в сообщениях писать, что изменили и зачем. Не смешивайте функциональные правки с массовым форматированием или большими правками документации — так проще ревьюить и потом искать причины регрессий. Для критичных изменений (например, схемы БД или контрактов MCP‑инструментов) часто удобно сначала обновить интерфейсы и документацию, потом — код, и только после этого мёржить в основную ветку.

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