Использование различных VCS репозиториев в PhpStorm

    Введение


    При развертывании проектов основанных на модульных приложениях (например, Magento) сталкиваешься с тем, что в проекте сосуществует код, находящийся в различных репозиториях. PhpStorm вполне хорошо справляется с подобной ситуацией. Допустим, у нас есть основной проект, расположенный на Github'е, в котором используются один новый модуль, расположенный там же, и один legacy-модуль, расположенный в SVN-репозитории:


    Работать одновременно с несколькими git-репозиториями позволяет механизм git submodules, а PhpStorm также позволяет к этому добавить и SVN-репозиторий.


    Формируем проект


    Клонируем основной проект, в котором еще нет субмодулей, на локальный диск:
    git clone https://github.com/praxigento/z_git_submodules_main.git
    cd .\z_git_submodules_main
    # добавляем субмодули
    git submodule add https://github.com/praxigento/z_mage_composer_mod_01.git modules/mod01
    


    В файле .gitmodules появлется нечто типа:
    [submodule "modules/mod_git"]
    	path = modules/mod_git
    	url = https://github.com/praxigento/z_mage_composer_mod_01.git
    


    При клонировании основного проекта, в котором уже подключены git-субмодули нужно дополнительно их инициировать:
    git submodule init
    git submodule update
    


    Удаление субмодуля
    По мотивам:
    git submodule deinit -f modules/mod01
    git rm -f  modules/mod01
    



    Отдельно подключаем SVN-модуль:
    svn co https://github.com/praxigento/z_mage_composer_mod_02/trunk modules/mod_svn
    


    Должна получится примерно такая файловая структура:


    Настройка PhpStorm


    Указываем в настройках PhpStrom все точки монтирования репоизториев в нашем проекте:


    Работа с изменениями


    Вносим изменения в README файлы в каждом из модулей и в самом проекте (всего три файла):


    Коммитим изменения в репозитории:


    Для git-репозиториев дополнительно push'аем изменения:


    Проверяем изменения во всех репозиториях:


    Таким образом, мы имеем возможность коммитить наши изменения в несколько репозиториев за раз.

    Обновление локального кода:

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 15

      +1
      Сабмодули зло, переходите на версионированные бинарные зависимости и будет счастье.
        0
        Чем плохи сабмодули? И как переходить на «версионированные бинарные зависимости» (и что то есть для PHP?), если для решения какого-либо таска мне нужно править исходный код сразу двух-трех модулей в рабочем окружении? Ну, допустим, я целевую систему соберу из «бинарников», а разрабатывать как?

        Ну и если сабмодули реальное зло, то "storm и без сабмодулей адекватно работает с несколькими репозиториями в одном проекте" (с) :)
          –1
          если «для решения какого-либо таска нужно править исходный код сразу двух-трех модулей в рабочем окружении», значит что-то не так в консерватории.
            0
            А у нас архитектура такая — есть модуль, в котором лежит функционал для всех наших проектов (задает поведение), есть модуль в котором идет реализация поведения для связанной группы проектов, есть модуль специализирующий поведение для конкретного проекта. И если я реализую базовую функцию, то я могу вносить изменения одновременно во все три модуля.
              0
              Сабмодули зло по многим причинам.

              1) Проблемы со сборкой, каждому разработчику нужно держать синхронизированное состояние сабмодулей
              2) Нет четкого понимания, какая версия сабмодуля требуется для сборки данной версии основного проекта
              3) Тяжело делать checkout к старым коммитам проекта, чтобы найти причину бага/фичи, если код связан с кодом из сабмодуля (придется понять к какому коммиту чекаутить сабмодуль, а что если сабмодулей много?)
              4) Сбока завязана на исходники сабмодулей, а это значит их нужно компилировать (в случае с php и другой интерпритарщиной не так критично), а это время, а время сборки критично важно для юнит-тестирования и вот этого всего.
              5) В какой-то момент вы начнете смешивать разработку проекта и сабмодулей, но может и нет. Энивей, когда модули толком не знают друг про друга, имеют свою семантическую версионированность и для вас это по-сути разные проекты, разрабатывать их становится проще, быстрее и правильнее во всех смыслах.
              6) Эта вечная херня с git submodule update, а еще --recursive, а еще… и т.д… Каждый раз, когда вы это делаете (особенно, если команда больше 1 человека), вы не находите это неправильным?
              7) Кто добавит?

              И если я реализую базовую функцию, то я могу вносить изменения одновременно во все три модуля.


              Прямо пункт 5.

              Как перевести всё на нормальные зависимости в php? Я без понятия — в Java: Gradle, Maven, у вас видимо Composer.
                0
                Спасибо за развернутый ответ. Для сборки prodcton-версии проекта я смотрю в сторону PHP Composer, сборку девелоперской версии без монтирования в проект исходников всех зависимых модулей, участвующих в разработке, я пока не представляю. Допустим, я могу отказаться от субмодулей gt'а, Но от монтирования в девелоперскую версию модулей, находящихся в различных репоизиториях (как того ожидает тот же composer) я уж точно не смогу отказаться. Это сильно затормозит (да что у ж там — остановит) проекты в которых я участвую — разработка e-commerce приложений на базе Magento. Я не представляю, каким образом эмулировать Magento для разработки Magento-модуля в «чистой среде», а особенно, когда у меня есть код, общий для всех наших проектов, и специализация кода под конкретный проект. А это минимум два модуля, которые должны девелопиться параллельно. А потом до общего модуля «докручивается» функционал специализированных модулей и в других проектах.

                ОК, вынес важную для себя мысль — сабмодули у народа не в подчете. Буду ступать осторожнее :)
        0
        storm и без сабмодулей адекватно работает с несколькими репозиториями в одном проекте
          0
          Добавлю:
          Althout Git integration supports work with multiple repositories in a single project, it doesn't support commands and workflows to work with Git submodules
          youtrack.jetbrains.com/issue/IDEA-64024

          Так что не всё хорошо с сабмодулями.
            0
            Если с сабмодулями не хорошо, то что в них плохого? По мне — так это просто нативный способ компоновать единый проект из разных репозиториев. То, что я в SVN делал при помощи sh/cmd-скриптов теперь могу делать нативно на уровне git'а. Насколько хорошо — другой вопрос. Но в чем зло? Или вы рекомендуете использовать старые-добрые shell-скрипты для монтирования проекта?

            В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте, но вот опыт MetalGuardian говорит о том, что PhpStorm и без этого неплохо справляется.
              0
              дело ещё в том, что шторм только на локальной машине, а на сервере нужно по другому управлять зависимостями.
              для этого лучше использовать composer
                0
                composer в стадии изучения :)
                0
                Вы ходили по ссылке? Она отнюдь говорит хорошо сабмодули или плохо. Это ссылка на багтрекер jetbrains, которые выпускаю intellij idea и производные (webstorm, phpstorm — в их числе). И обсуждаемый баг — плохая поддержка сабмодулей.
                  0
                  Ходил.
                  В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте...

                  Или я неправильно понял?
                  Я вижу, что на данный момент PhpStorm позволяет коммитить в разные репозитории изменения за один подход и обновлять их. Насколько я понял MetalGuardian, это фича самого PhpStorm'а, не зависящая от git'а. Т.е., этот функционал обеспечивается PhpStrom'ом без использования функционала git submodules. Разве нет?
                    0
                    Да, это функционал IntelliJ IDEA. И оно работает хорошо с проектами в которых несколько репозиториев. Но при этом, если вы используете сабмодули — то часть вещей ломается (например, checkout другой ветки до недавнего времени был сломан).
              0
              Вспоминаю работу с сабмодулями как страшный сон.
              composer позволяет устранить ошибки с сабмодулями, связанными с человеческим фактором, и переключаться между ветками проще с ним.

              Only users with full accounts can post comments. Log in, please.