Поддержание проекта с плагинами в git

Question

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

I.e. должен ли мы помещать каждый плагин в свой собственный репозиторий git? Это может показаться логичным выбором, поскольку плагины в основном не зависят друг от друга и довольно автономны (просто используют основное приложение для функциональных возможностей фреймворка и управления общими функциями), которые часто разрабатываются разными людьми и иногда устаревают. Однако теперь есть более дюжины плагинов с еще большим количеством, и для создания всего проекта обычно требуется проверять все (или большинство) плагинов по одному. И, кажется, нет простого способа проверить ВСЕ их сразу, т. Е. Там, вероятно, должен быть какой-то «список», чтобы люди знали, что получить, а что нет.

С другой стороны, помещение всего в один репозиторий git кажется не в духе git, особенно. поскольку мы будем носить старый мертвый код и работать над одним плагином, потребуется проверить много кода (хотя тогда большинство разработчиков, работающих над ним, все равно проверили бы все). Также ветвление всегда будет разветвляться всем (что делает, например, кросс-тестирование разветвленных функций сложным, если плагины не могут разветвляться отдельно)

Одна из идей заключается в использовании подмодулей, но я не знаю, накладные расходы (умственные накладные расходы , Я имею в виду) больше, чем выигрыш (или мы получаем меньше, чем теряем с использованием подхода «один за другим»).

Как бы справиться с этим проектом в git?

Answer 1

Этот вид системы (как в «коллекции перезаписываемых компонентов») будет лучше управляться с:

• каждый плагин в своем собственном хранилище
• один родительский проект, который бы объявить все соответствующие подключаемые модули подмодули.

Как указано в «true nature of submodules», вы можете затем модифицировать любой плагин непосредственно из этого одного родительского проекта.
(см. Также Duplicate submodules with Git, если у вас есть повторяющиеся зависимости) И последние выпуски Git поставляются с командами, способными рекурсивно проверять все подмодули родительского проекта.

---

Так что, когда я проверить родительский проект, и не забудьте позвонить «git submodule init» для каждого плагина, я бы все проекты на моем рабочем столе.

Но вы не должны помнить, чтобы сделать что-нибудь кроме git submodule update --init --recursive (только один команды). Как я уже сказал, он будет рекурсивно инициализировать все ваши подмодули.

Однако submodules are pinned to versions, не будет ли это причиной более сложного рабочего процесса?

Принцип управления зависимостями - всегда ссылаться на определенную версию (в отличие от ссылки «последний код там» для одного компонента).
Но это не мешает вам:

• работы в этом компоненте (работа с этой конкретной версии * в качестве отправной точки ")
• совершить
• толчок, что один компонент его удаленный репозиторий
• перейти на один уровень вверх, обратно в родительском проекте
• совершить родительский проект (для того, чтобы ссылаться на новой версии субмодуля вы просто модифицированным)

Снова, true nature of submodules детали, которые обрабатываются.