На многих веб-проектах, особенно, после запуска наступает стадия когда работа над сайтом не укладывается в идеальную схему применения системы контроля версий. Данная статья расскажет об упрощенной схеме использования git.
Важным нюансом является возможность изменения файлов персоналом сайта на рабочем сервере. Изменения могут быть обоснованные. Например, в некоторых случаях СЕО параметры хранятся именно в файлах, так же контент-менеджеры могут редактировать тексты статических страниц и включаемых областей. А обладая правами администратора можно отредактировать любой файл сайта. Кроме того на практике после запуска над сайтом работают не связанные между собой люди, не все из них умеют обращаться с git и нет рычагов влияния на них. Т.е. при работе над таким проектом лучше иметь в виду, что правки на рабочем сервере возможны.
Итак. В репозитории всегда присутствуют две обязательные ветки: master - соответствует состоянию рабочего сервера (продакшн) и dev - состояние сервера разработки (дев). Если над проектом работают несколько разработчиков, то полезно будет иметь каждому свою ветку. Так же создаются ветки на задачи, которые необходимо выполнить параллельно с основной разработкой.
Для начала необходимо создать репозиторий на рабочем сервере. Репозитория я обычно располагаю на уровень выше в файловой системе чем корень сайта. Минимальный .gitignore при этом (для примера корень сайта в каталоге www)
www/bitrix/ www/upload/
Остальные исключения зависят от конкретного проекта.
Как можно обратить внимание я исключаю весь каталог bitrix из репозитория. Это возможно за счет того, для разработки используется каталог local, в котором располагаются шаблоны, php_interface и прочие необходимые каталоги и файлы. А исключение из репозитория ядра битрикс необходимо для быстрого выполнения коммитов. Т.к. при включенном слежении за ядром, каждый коммит происходит заметно дольше. При этом ядро гит я все же рекомендую помещать в собственный репозиторий внутри каталога bitrix. При этом стоит проработать содержание .gitgnore в этом каталоге. Это бывает полезно при обновлениях, чтобы была возможность проверить изменения. Бывает возникают ситуации, когда вы сами нашли и исправили баг в ядре, а разработчики не спешат с обновлением.
После создания репозитория, выполнения добавления файлов и коммита на рабочем сервере необходимо создать резервную копию сайта. Далее из этой копии развернуть сайт на сервере разработки. Копирую туда же каталог с репозиторием (.git). Расположить этот каталог относительно корня необходимо так же как и на рабочем сервере. После чего настраиваем удаленный репозиторий (на рабочем сервере) командой
git remote add prod путь_к_репозитоию_на_рабочем_сервере
и выполняем контрольный pull. Следующим этапом создаем ветку разработки dev и переключаем проект на нее. Таким же образом необходимо развернуть копии для разработчиков.
При работе с этими копиями и репозиториями первой сложностью является синхронизация базы данных. И тут все зависит от вносимых изменений. Например добавление новых свойств и инфоблоков я начинаю с рабочего сайта и тут же создаю на сайте разработки. Делаю это для того что бы идентификаторы этих сущностей были одинаковыми.
Для простоты пояснений беру ситуацию когда разработчик один и разработка ведется непосредственно на сервере разработки. Если разработчиков несколько и у каждого свой сервер действия будут те же самые только между сервером разработчика и общим сервером разработки.
После выполнения очередной задачи и проведения тестирования произвожу коммит на сервере разработки в ветке dev. На рабочем сервере выполняю коммиит (на тот случай если кто-то внес изменения на нем) в ветке master. Далее на сервере разработки перехожу в ветку master и выполняю pull с продакшна. Перехожу в ветку dev и выполняю merge с веткой master. На этом этапе необходимо проработать все конфликты, которые не смог решить автоматически git. После того как все проблемы решены выполняю push в ветку dev рабочего сервера. После чего уже на рабочем сервере из ветки master выполняю merge ветки dev.
Вся операция обновления получилась в достаточно много ходов. Тем не менее она обеспечивает надежность и, фактически, много времени не занимает. Для удобства у меня на одном из рабочих столов (я использую Linux) открыты два терминала: рабочий сервер и сервер разработки.
На практике возникали случаи когда не было ssh доступен на рабочем. Для решения этой проблемы я использую модуль Консоль Git