Перейти к содержимому

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-only
chown -R bitrix:bitrix /home/bitrix/www/local
find /home/bitrix/www/local -type f -exec chmod 644 {} \;
# файл от чужого владельца платформа прочитает, но не перезапишет
# состав репозитория проверяют на чистой копии перед первой выкладкой
# каталог загрузок и кэш в репозиторий не кладут: они растут и мешают слиянию

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

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

Правки прямо на боевом сайте лишают историю смысла. Файл, поправленный руками и не попавший в репозиторий, исчезнет при следующей выкладке, а автор правки к тому времени про неё забудет.

Кэш после каждой выкладки сбрасывают отдельным действием. Новый код и старый кэш - обычная причина странностей вроде «у меня работает, а на сайте нет» сразу после переноса.

Типичные проблемы

Репозиторий весит гигабайты.

В него попал каталог ядра платформы или каталог загрузок. Оба ставятся и растут вне системы контроля версий.

Пароль базы виден в истории изменений.

Файл с настройками подключения к базе попал под контроль версий. Такие файлы держат вне репозитория с самого начала работы.

После выкладки сайт не пишет файлы.

Владелец новых файлов не совпадает с пользователем процессов PHP. Права возвращают на место сразу после переноса файлов.

Правка исчезла после выкладки.

Её сделали прямо на боевом сайте, минуя репозиторий проекта. Перенос вернул файл к последней версии из истории изменений.

Новый код ведёт себя как старый.

После выкладки правок не сброшен кэш сайта. Страницы и компоненты продолжают отдавать прежний результат.

Частые вопросы

А если решение из каталога правится под проект?

Копию правленого решения держат в своём каталоге, а не в каталоге модулей платформы. Иначе обновление вернёт исходный код.

Как переносить структуру базы?

Скриптами обновления своего модуля или отдельными миграциями. Ручные правки структуры на боевом сайте не воспроизводятся на стенде.

Нужен ли отдельный стенд каждому разработчику?

Да, иначе правки перетирают друг друга. Общий стенд оправдан только для приёмки.

Что делать с публичными страницами, которые правит контент-менеджер?

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

Смежное

Первоисточник