Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Сабмодули зло, переходите на версионированные бинарные зависимости и будет счастье.
Чем плохи сабмодули? И как переходить на «версионированные бинарные зависимости» (и что то есть для PHP?), если для решения какого-либо таска мне нужно править исходный код сразу двух-трех модулей в рабочем окружении? Ну, допустим, я целевую систему соберу из «бинарников», а разрабатывать как?
Ну и если сабмодули реальное зло, то "storm и без сабмодулей адекватно работает с несколькими репозиториями в одном проекте" (с) :)
Ну и если сабмодули реальное зло, то "storm и без сабмодулей адекватно работает с несколькими репозиториями в одном проекте" (с) :)
если «для решения какого-либо таска нужно править исходный код сразу двух-трех модулей в рабочем окружении», значит что-то не так в консерватории.
А у нас архитектура такая — есть модуль, в котором лежит функционал для всех наших проектов (задает поведение), есть модуль в котором идет реализация поведения для связанной группы проектов, есть модуль специализирующий поведение для конкретного проекта. И если я реализую базовую функцию, то я могу вносить изменения одновременно во все три модуля.
Сабмодули зло по многим причинам.
1) Проблемы со сборкой, каждому разработчику нужно держать синхронизированное состояние сабмодулей
2) Нет четкого понимания, какая версия сабмодуля требуется для сборки данной версии основного проекта
3) Тяжело делать checkout к старым коммитам проекта, чтобы найти причину бага/фичи, если код связан с кодом из сабмодуля (придется понять к какому коммиту чекаутить сабмодуль, а что если сабмодулей много?)
4) Сбока завязана на исходники сабмодулей, а это значит их нужно компилировать (в случае с php и другой интерпритарщиной не так критично), а это время, а время сборки критично важно для юнит-тестирования и вот этого всего.
5) В какой-то момент вы начнете смешивать разработку проекта и сабмодулей, но может и нет. Энивей, когда модули толком не знают друг про друга, имеют свою семантическую версионированность и для вас это по-сути разные проекты, разрабатывать их становится проще, быстрее и правильнее во всех смыслах.
6) Эта вечная херня с git submodule update, а еще --recursive, а еще… и т.д… Каждый раз, когда вы это делаете (особенно, если команда больше 1 человека), вы не находите это неправильным?
7) Кто добавит?
Прямо пункт 5.
Как перевести всё на нормальные зависимости в php? Я без понятия — в Java: Gradle, Maven, у вас видимо Composer.
1) Проблемы со сборкой, каждому разработчику нужно держать синхронизированное состояние сабмодулей
2) Нет четкого понимания, какая версия сабмодуля требуется для сборки данной версии основного проекта
3) Тяжело делать checkout к старым коммитам проекта, чтобы найти причину бага/фичи, если код связан с кодом из сабмодуля (придется понять к какому коммиту чекаутить сабмодуль, а что если сабмодулей много?)
4) Сбока завязана на исходники сабмодулей, а это значит их нужно компилировать (в случае с php и другой интерпритарщиной не так критично), а это время, а время сборки критично важно для юнит-тестирования и вот этого всего.
5) В какой-то момент вы начнете смешивать разработку проекта и сабмодулей, но может и нет. Энивей, когда модули толком не знают друг про друга, имеют свою семантическую версионированность и для вас это по-сути разные проекты, разрабатывать их становится проще, быстрее и правильнее во всех смыслах.
6) Эта вечная херня с git submodule update, а еще --recursive, а еще… и т.д… Каждый раз, когда вы это делаете (особенно, если команда больше 1 человека), вы не находите это неправильным?
7) Кто добавит?
И если я реализую базовую функцию, то я могу вносить изменения одновременно во все три модуля.
Прямо пункт 5.
Как перевести всё на нормальные зависимости в php? Я без понятия — в Java: Gradle, Maven, у вас видимо Composer.
Спасибо за развернутый ответ. Для сборки prodcton-версии проекта я смотрю в сторону PHP Composer, сборку девелоперской версии без монтирования в проект исходников всех зависимых модулей, участвующих в разработке, я пока не представляю. Допустим, я могу отказаться от субмодулей gt'а, Но от монтирования в девелоперскую версию модулей, находящихся в различных репоизиториях (как того ожидает тот же composer) я уж точно не смогу отказаться. Это сильно затормозит (да что у ж там — остановит) проекты в которых я участвую — разработка e-commerce приложений на базе Magento. Я не представляю, каким образом эмулировать Magento для разработки Magento-модуля в «чистой среде», а особенно, когда у меня есть код, общий для всех наших проектов, и специализация кода под конкретный проект. А это минимум два модуля, которые должны девелопиться параллельно. А потом до общего модуля «докручивается» функционал специализированных модулей и в других проектах.
ОК, вынес важную для себя мысль — сабмодули у народа не в подчете. Буду ступать осторожнее :)
ОК, вынес важную для себя мысль — сабмодули у народа не в подчете. Буду ступать осторожнее :)
storm и без сабмодулей адекватно работает с несколькими репозиториями в одном проекте
Добавлю:
Так что не всё хорошо с сабмодулями.
Althout Git integration supports work with multiple repositories in a single project, it doesn't support commands and workflows to work with Git submodulesyoutrack.jetbrains.com/issue/IDEA-64024
Так что не всё хорошо с сабмодулями.
Если с сабмодулями не хорошо, то что в них плохого? По мне — так это просто нативный способ компоновать единый проект из разных репозиториев. То, что я в SVN делал при помощи sh/cmd-скриптов теперь могу делать нативно на уровне git'а. Насколько хорошо — другой вопрос. Но в чем зло? Или вы рекомендуете использовать старые-добрые shell-скрипты для монтирования проекта?
В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте, но вот опыт MetalGuardian говорит о том, что PhpStorm и без этого неплохо справляется.
В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте, но вот опыт MetalGuardian говорит о том, что PhpStorm и без этого неплохо справляется.
дело ещё в том, что шторм только на локальной машине, а на сервере нужно по другому управлять зависимостями.
для этого лучше использовать composer
для этого лучше использовать composer
Вы ходили по ссылке? Она отнюдь говорит хорошо сабмодули или плохо. Это ссылка на багтрекер jetbrains, которые выпускаю intellij idea и производные (webstorm, phpstorm — в их числе). И обсуждаемый баг — плохая поддержка сабмодулей.
Ходил.
Или я неправильно понял?
Я вижу, что на данный момент PhpStorm позволяет коммитить в разные репозитории изменения за один подход и обновлять их. Насколько я понял MetalGuardian, это фича самого PhpStorm'а, не зависящая от git'а. Т.е., этот функционал обеспечивается PhpStrom'ом без использования функционала git submodules. Разве нет?
В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте...
Или я неправильно понял?
Я вижу, что на данный момент PhpStorm позволяет коммитить в разные репозитории изменения за один подход и обновлять их. Насколько я понял MetalGuardian, это фича самого PhpStorm'а, не зависящая от git'а. Т.е., этот функционал обеспечивается PhpStrom'ом без использования функционала git submodules. Разве нет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование различных VCS репозиториев в PhpStorm