Макет большого проекта: добавление новой функции в несколько подпроектов

Я хочу знать, как управлять большим проектом со многими компонентами с помощью системы управления версиями.

В моем текущем проекте 4 основных части.

1. Web
2. сервер
3. Консоль администратора
4. Платформа.

В веб и серверной части используются 2 библиотеки, которые я написал. Всего существует 5 репозиториев Git и 1 репозиторий Mercurial. Скрипт сборки проекта находится в репозитории Platform. Это автоматизирует весь процесс строительства.

Проблема в том, что когда я добавляю новую функцию, которая влияет на несколько компонентов, мне нужно создать ветку для каждого из затронутых репо. Реализуйте эту функцию. Слей его обратно. Я чувствую, что что-то не так.

Так я должен создать единый репо и поместить все компоненты там? Я думаю, что в этом случае ветвление будет легче. Или я просто делаю то, что делаю прямо сейчас. В таком случае, как мне решить эту проблему создания ветки в каждом хранилище?

В описываемой вами ситуации вы не получаете никакой выгоды от наличия нескольких репозиториев, но у вас есть затраты: вы не можете откатиться к более старой версии репозитория и уверены, что ваша система продолжит работать. Это потому, что ваш код тесно связан между хранилищами. Поскольку уверенность в возможности отката является одним из основных преимуществ контроля версий, вам не нужно находиться в такой ситуации.

Решение состоит в том, чтобы определить структуру вашего репозитория на основе связывания кода внутри него: если компонент проекта A имеет только стабильные интерфейсы с компонентом B проекта, то они могут быть размещены в отдельных репозиториях. В противном случае они должны быть расположены в одном и том же хранилище. Более детальная компоновка репозитория будет отражать более качественную архитектуру системы.

Если каждый из ваших репозиториев является автономным проектом или библиотекой, то я бы сказал, что в создании репозитория компонентов каждого репозитория нет ничего плохого при добавлении новых функций, которые пересекают проекты. Будучи автономными, каждый из них может иметь независимую версию, и вы можете отказаться от старых API.

Но в вашем конкретном случае кажется, что ваши репозитории могут не эффективно группировать ваш код. Если изменения в коде в одном репозитории требуют изменений в других (кроме устаревших), то либо ваша связь слишком жесткая, либо репозитории должны быть реорганизованы.

Если все репозитории действительно являются частью одного проекта (они не могут оставаться в одиночестве), то, возможно, у вас должен быть только 1 репозиторий. (Или, может быть, 2: основной проект и один для общей / стандартизированной функциональности.)