Я хочу знать, как управлять большим проектом со многими компонентами с помощью системы управления версиями.
В моем текущем проекте 4 основных части.
- Web
- сервер
- Консоль администратора
- Платформа.
В веб и серверной части используются 2 библиотеки, которые я написал. Всего существует 5 репозиториев Git и 1 репозиторий Mercurial. Скрипт сборки проекта находится в репозитории Platform. Это автоматизирует весь процесс строительства.
Проблема в том, что когда я добавляю новую функцию, которая влияет на несколько компонентов, мне нужно создать ветку для каждого из затронутых репо. Реализуйте эту функцию. Слей его обратно. Я чувствую, что что-то не так.
Так я должен создать единый репо и поместить все компоненты там? Я думаю, что в этом случае ветвление будет легче. Или я просто делаю то, что делаю прямо сейчас. В таком случае, как мне решить эту проблему создания ветки в каждом хранилище?
источник
Ответы:
В описываемой вами ситуации вы не получаете никакой выгоды от наличия нескольких репозиториев, но у вас есть затраты: вы не можете откатиться к более старой версии репозитория и уверены, что ваша система продолжит работать. Это потому, что ваш код тесно связан между хранилищами. Поскольку уверенность в возможности отката является одним из основных преимуществ контроля версий, вам не нужно находиться в такой ситуации.
Решение состоит в том, чтобы определить структуру вашего репозитория на основе связывания кода внутри него: если компонент проекта A имеет только стабильные интерфейсы с компонентом B проекта, то они могут быть размещены в отдельных репозиториях. В противном случае они должны быть расположены в одном и том же хранилище. Более детальная компоновка репозитория будет отражать более качественную архитектуру системы.
источник
Если каждый из ваших репозиториев является автономным проектом или библиотекой, то я бы сказал, что в создании репозитория компонентов каждого репозитория нет ничего плохого при добавлении новых функций, которые пересекают проекты. Будучи автономными, каждый из них может иметь независимую версию, и вы можете отказаться от старых API.
Но в вашем конкретном случае кажется, что ваши репозитории могут не эффективно группировать ваш код. Если изменения в коде в одном репозитории требуют изменений в других (кроме устаревших), то либо ваша связь слишком жесткая, либо репозитории должны быть реорганизованы.
Если все репозитории действительно являются частью одного проекта (они не могут оставаться в одиночестве), то, возможно, у вас должен быть только 1 репозиторий. (Или, может быть, 2: основной проект и один для общей / стандартизированной функциональности.)
источник