Git в проекте на платформе - состав репозитория и выкладка
Заводим репозиторий на проекте: разбираем, что версионировать, что оставить платформе и как выкладывать правки, не ломая права на файлы.
Решение
Смотрим, что вообще стоит версионировать:
du -sh /home/bitrix/www/bitrix /home/bitrix/www/local /home/bitrix/www/upload# ядро ставит и обновляет платформа, загрузки растут сами# свой код проекта живёт в local: шаблоны, модули, обработчикиПод контролем версий держат только каталог своего кода. Ядро весит гигабайты и обновляется платформой, загрузки растут непредсказуемо, и оба каталога в репозитории только мешают.
Настраиваем список игнорируемого:
# .gitignore в корне проекта/bitrix//upload//local/php_interface/dbconn.php/bitrix/.settings.php/bitrix/.settings_extra.php*.log# каталоги кэша и служебные файлы тоже не версионируютсяСписок игнорируемого начинают с ядра и загрузок, а продолжают файлами с паролями. Пароль, попавший в историю изменений, остаётся там навсегда, даже после его смены на боевом сайте.
Разводим настройки стендов:
// /bitrix/.settings_extra.php - файл стенда, вне репозиторияreturn [ 'connections' => ['value' => ['default' => ['host' => 'localhost']]], 'cache' => ['value' => ['type' => 'files']],];Настройки стенда лежат в отдельном файле, который не версионируется. Тогда один и тот же код работает и на боевом сайте, и на копии разработчика без правки файлов перед каждым запуском.
Выкладываем правки и чиним права:
git -C /home/bitrix/www pull --ff-onlychown -R bitrix:bitrix /home/bitrix/www/localfind /home/bitrix/www/local -type f -exec chmod 644 {} \;# файл от чужого владельца платформа прочитает, но не перезапишет# состав репозитория проверяют на чистой копии перед первой выкладкой# каталог загрузок и кэш в репозиторий не кладут: они растут и мешают слияниюПосле переноса обязательно проверяют владельца новых файлов. Выкладка от имени администратора сервера оставляет каталоги, в которые сайт не может писать, и жалобы приходят не сразу, а при первой попытке что-нибудь сохранить.
Ветку под каждую задачу заводят с первого дня, а не когда станет тесно. Разбор чужой правки в общей ветке через месяц стоит дороже, чем привычка называть ветки по задачам с самого начала.
Правки прямо на боевом сайте лишают историю смысла. Файл, поправленный руками и не попавший в репозиторий, исчезнет при следующей выкладке, а автор правки к тому времени про неё забудет.
Кэш после каждой выкладки сбрасывают отдельным действием. Новый код и старый кэш - обычная причина странностей вроде «у меня работает, а на сайте нет» сразу после переноса.
Типичные проблемы
Репозиторий весит гигабайты.
В него попал каталог ядра платформы или каталог загрузок. Оба ставятся и растут вне системы контроля версий.
Пароль базы виден в истории изменений.
Файл с настройками подключения к базе попал под контроль версий. Такие файлы держат вне репозитория с самого начала работы.
После выкладки сайт не пишет файлы.
Владелец новых файлов не совпадает с пользователем процессов PHP. Права возвращают на место сразу после переноса файлов.
Правка исчезла после выкладки.
Её сделали прямо на боевом сайте, минуя репозиторий проекта. Перенос вернул файл к последней версии из истории изменений.
Новый код ведёт себя как старый.
После выкладки правок не сброшен кэш сайта. Страницы и компоненты продолжают отдавать прежний результат.
Частые вопросы
А если решение из каталога правится под проект?
Копию правленого решения держат в своём каталоге, а не в каталоге модулей платформы. Иначе обновление вернёт исходный код.
Как переносить структуру базы?
Скриптами обновления своего модуля или отдельными миграциями. Ручные правки структуры на боевом сайте не воспроизводятся на стенде.
Нужен ли отдельный стенд каждому разработчику?
Да, иначе правки перетирают друг друга. Общий стенд оправдан только для приёмки.
Что делать с публичными страницами, которые правит контент-менеджер?
Держать их вне репозитория: их правят через интерфейс. Версионируют шаблоны и код, а не содержимое страниц.
Смежное
- Git и выкладка - оглавление подтемы
- Сторонняя библиотека в проекте: composer, автозагрузка, выкладка - что делать с каталогом библиотек
- Архитектура проекта - что где лежит в проекте
- Свой модуль: структура, установка, автозагрузка - главный житель репозитория
- Права на файлы и папки: файловая система и права структуры - владелец файлов после выкладки
- Миграции структуры: перенос инфоблоков и настроек между стендами - перенос структуры базы вместе с кодом
- Правка не видна на сайте: какой кэш сбросить - что сбросить после переноса
- Настройки проекта: файл ядра, опции модуля, разные стенды - куда убрать пароли и ключи
- Выкладка на боевой: порядок, структура, откат - шаги самого релиза