В этой статье будут рассмотрены основные приемы работы с подмодулями гита, если использовать их вместе с друпалом.
Наиболее полезным этот пост будет для тех кто, имея скромный опыт работы с гитом, попал на Drupal-проект где используются подмодули. (Именно так я познакомился с подмодулями и именно такой статьи мне в то время очень не хватало.)
Условия
У нас есть линукс, установлен drush и есть инсталяция седьмого друпала. Основной репозиторий хранит в себе ядро друпала (и, возможно, наши кастомные модули). Все команды выполняются из корневого каталога исталяции друпала, если не указано иное. Модуль — модуль друпала, подмодуль — подмодуль гита.
Минимум информации о подмодулях
Подмодули — это обычные гит репозитории. Они хранятся отдельно от основного репозитория.
В репозитории проекта хранится список используемых подмодулей, их расположение и УРЛы (в файле .gitmodules) и информация о том какое конкретное состояние (версия/релиз/коммит/тег) подмодуля будет использовано (в недрах каталога .git).
Обновление проекта
Если в вашем проекте используются подмодули, то лучше всего каждый раз после git pull выполнять еще и эти команды:
git submodule sync # обновляем используемые УРЛы репозиториев
git submodule update --init # устанавливаем новые подмодули и обновляем состояние уже установленных
Установка модуля
Команда драша dl умеет работать с модулями как с подмодулями гита:
drush dl module_name --package-handler=git_drupalorg --gitsubmodule
Драш поддерживает работу только с официальным репозиторием — git.drupal.org.
Что бы постоянно не писать дополнительные параметры команды dl, можно настроить значения параметров драша используемые по умолчанию добавив в drushrc.php следующие строки:
$options['package-handler'] = 'git_drupalorg';
$options['gitsubmodule'] = TRUE;
В этом случае все модули по умолчанию будут скачиваться как подмодули гита и можно писать просто:
drush dl module_name
Если же подмодуль нужно установить вручную, например, не из официального репозитория, тогда пользуемся обычной коммандой гита:
git submodule add git://github.com/example/module_name.git sites/all/modules/module_name
После чего нужно перейти в каталог установленного подмодуля и переключиться на нужный релиз:
git checkout 7.x-1.0
Определение версии модуля
Если скачать модуль «по старинке» с сайта drupal.org, то версия модуля будет указана в файле module_name.info. Она добавляется в этот файл автоматически при создании релиза, в репозитории ее нет.
Что бы друпал сам мог определять версию модулей нужен модуль git_deploy. Он дополняет информацию полученную друпалом из info-файлов добавляя в нее версию модуля, которую он «добывает» используя различные команды гита. Использовать подмодули без git_deploy можно, но вы не сможете пользоваться обновлением через drush up, потому что друпал не будет знать текущей версии установленных модулей.
Узнать версию модуля можно еще и так:
git submodule status | grep module_name
В скобках будет указан тег который используется в нашем проекте.
Обновление модуля
Команда для обновления используется самая обычная:
drush up module_name
Опять же, она будет работать только если у нас установлен git_deploy.
Если нам нужно обновить модуль вручную, скажем, мы хотим обновится до определенной версии. Тогда из каталога подмодуля запускаем две команды:
git fetch # обновляем информацию из удаленного репозитория
git checkout 7.x-3.5 # переключаем код на требуемый релиз (тег)
После этого не забываем запустить обновления базы данных:
drush updb
Патч модуля
Сначала желательно переключить подмодуль на определенный бранч потому как
- патчи в основном пишутся для dev-версий
- драш «нацеливает» подмодуль на определенный релиз (тег), а это означает что ваш подмодуль находится в состоянии «detached head» и дальнейшая работа может быть затруднена.
Например, если мы использовали версию модуля 7.x-3.5, переключимся на рабочую ветку этого релиза:
git fetch # обновляем информацию из удаленного репозитория
git checkout 7.x-3.x # переключаемся на рабочую ветку
git pull # обновляем ветку
Применям патч используя командную строку, вашу любимую IDE или прочие инструменты.
Создаем отдельный репозиторий для модуля который мы пропатчили. Например, на гитхабе.
Обновляем УРЛ репозитория вашего подмодуля. Для этого находим соответствующую секцию в файле .gitmodules, например:
[submodule "sites/all/modules/module_name"]
path = sites/all/modules/module_name
- url = git://git.drupal.org/project/module_name.git
+ url = https://github.com/example/module_name.git
Что бы гит начал использовать новый УРЛ, выполняем:
git sybmodule sync
Теперь можно закоммитить наши изменения и запушить всё в наш новый репозиторий. Из каталога подмодуля выполняем:
git commit -m "Applied patch from http://drupal.org/node/00000#comment-0000000"
git push
В ваш репозиторий попадет и ваш коммит и вся предыдущая история модуля.
Обновление пропатченого модуля
Иногда требуется обновить модуль в который мы вносили свои изменения, например, в связи с выходом обновления безопасности или появления новых нужных нам фич.
Самым простым решением будет обновление из рабочей ветки официального репозитория. Например, если ранее мы пропатчили модуль на основе бранча 7.x-3.x, из каталога его подмодуля запускаем:
git pull http://git.drupal.org/project/module_name.git 7.x-3.x
(Если честно, это единственный способ которым я пользовался до этого момента.)
Восстановление репозитория
Если ваш патч закоммитили или же он больше не нужен, есть смысл вернуть подмодуль на обеспечение git.drupal.org. Для этого обновляем (возвращаем прежний) УРЛ, снхронизируем УРЛы подмодулей, делаем git fetch из каталога подмодуля и чекаутим нужный релиз. Все это описано выше.
Удаление подмодуля
Простой команды нет, но есть рецепт со stackoverflow:
- удаляем секции подмодуля из файлов
.gitmodulesи.git/config, - выполняем
git rm --cached sites/all/modules/module_name, - коммитим изменения и удаляем каталог подмодуля.
Заключение
В контексте друпала использование подмодулей дает ряд преимуществ. Патчить модули становится удобней, а поддерживать их при этом в актуальном состоянии — легко. Вы можете использовать пропатченые или ваши собственные модули в нескольких проектах, при этом централизованно ведя работу над ними. А если учесть, что для работы с подмодулями нужно освоить всего лишь несколько простых приемов, то мы получаем сплошные плюсы и делаем вывод что подмодули — это простой и эффективный инструмент который можно и нужно использовать в Drupal-проектах.
Автор: Leksat
