Ведение проекта с плагинами в git - PullRequest
3 голосов
/ 30 ноября 2010

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

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

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

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

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

1 Ответ

4 голосов
/ 30 ноября 2010

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

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

Как указано в " истинной природе подмодулей ", вы можете затем изменить любой плагин непосредственно из этого одного родительского проекта.
(См. Также Дублирующиеся подмодули с Git , если у вас есть дублирующиеся зависимости) А последние выпуски Git поставляются с командами, способными рекурсивно извлекать все подмодули родительского проекта.


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

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

Однако подмодули прикреплены к версиям , не вызовет ли это более сложный рабочий процесс?

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

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

Опять же, истинная природа подмодулей подробно описывает этот процесс.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...