Как эффективно использовать систему контроля версий (Git) при разработке на Битрикс

Зачем нужен git? Что положить в .gitignore? Как именовать коммиты? Зачем нужны ветки? Мерж или пул-реквест? Сегодня поговорим об эффективном использовании системы контроля версий git на проектах под 1С-Битрикс.

Наиболее популярной системой контроля версий (Version Control System — VCS) в мире веб-разработки является git. Это прекрасный инструмент, который сохранит вам невероятное количество времени и нервов при работе над проектом. Даже если проект — ваш личный сайт, над которым работаете только вы.

Многие новички часто думают, что git и github\gitlab\и т. д. — это одно и то же, однако между этими понятиями огромная разница.

Из определения видно, что задачи, стоящие перед программой git и обозначенными веб-сервисам, совершенно разные.

Можно без преувеличения сказать, что git — это машина времени, позволяющая путешествовать исключительно в прошлое. Неважно, работаете вы один или в команде, вам нужен git. Он помогает фиксировать все-все изменения по проекту, обеспечивает удобный CLI (Command-Line Interface — интерфейс командной строки), позволяет одной командой обновить код на продакшене и еще очень много чего.

Для начала работы с git необходимо инициализировать репозиторий. Что такое репозиторий? Это централизованное хранилище для вашего кода. Для инициализации используется команда:

После ее выполнения в корне вашего проекта появится неприметная папка .git, где и будет храниться вся история изменений проекта.

Далее стоит подумать, а все ли файлы и папки нам нужно хранить в репозитории? Как правило, на проектах под 1С-Битрикс ответ на вопрос будет отрицательный.

Чтобы указать git’у, какие файлы и папки НЕ должны попасть в репозиторий, используется файл .gitignore. Он располагается в корне проекта. Синтаксис его довольно прост: на каждой новой строке указывается файл, тип файла или папки, которые не нужны в репозитории.

Мы рекомендуем исключать из репозитория следующие пункты:

Базовый gitignore будет выглядеть так:

/bitrix

/upload

*.log

*.log.*

*.txt

.htaccess

.htpasswd

.htaccess.restore

Далее вы можете наполнять его согласно своим требованиям.

Теперь пришло время отправить первый коммит в репозиторий.

Для этого потребуется выполнить четыре команды:

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

git@github.com:example_user/repository_name.git — для связки локального и удаленного репозиториев. Где example_user — имя вашего профиля, repository_name — название репозитория.

Мы в #RACURS Agency используем общепринятую систему именования коммитов. Если кратко — сообщение делится на две логические части: действие и пояснение. Например, fix: header contacts button — уже из названия коммита можно понять, над чем трудился разработчик и что он делал. В данном случае, скорее всего, поправлял кнопку «Контакты» в шапке сайта.

Также полезно будет в конце сообщения указывать ссылку на задачу из вашей тикет-системы. Таким образом итоговое сообщение коммита внутри нашей команды выглядит так:

fix: contacts page form button [https://out-ticket-system.ru/some-task]

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

Ветки (branch) в гите — это крайне мощная концепция. Представим умозрительную ситуацию: клиент отдает в работу две крупные, но не связанные друг с другом задачи. Как реализовать их параллельно? Здесь нам и пригодятся ветки.

Благодаря гиту мы можем «отпочковаться» от master ветки и вести работу независимо от изменений, поступающих в master. Например, можно создать отдельную ветку на каждую крупную задачу и вести разработку там.

Какие плюсы это даст? Например, мы не стали создавать отдельные ветки, работали над крупной задачей в master’e и сделали половину, но пришел клиент и говорит, что у него что-то сломалось на сайте. Можем ли мы внести хотфикс в master? Нет, потому как в таком случае наполовину НЕсделанная задача также уйдет в прод, а это плохо и неправильно.

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

Ветки снимают с нас эту головную боль как раз за счет распараллеливания хранилища кода.

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

Логическим окончанием жизненного цикла ветки является запрос на перенос внедренных изменений в master ветку для последующего выката в прод.

Запрос на перенос внедренных изменений в другую ветку называется pull request — в github, и merge request — в gitlab. Разницы между ними нет, кроме названия .

После создания pull\merge request’а git проанализирует внедренные изменения и, если возможно, предложит сделать автоматическое слияние (merge). Если же автоматическое слияние невозможно, git укажет разработчику места в коде, где возникли конфликты.

Конфликты возникают по разным причинам. Наиболее часто встречаются в практике следующие ситуации:

И если измененные файлы в нашей ветке и в мастере пересекаются — будет конфликт.

Разрешать конфликты довольно просто. Популярные IDE, как правило, предоставляют функционал для этого. Если кратко описывать суть процесса, то необходимо в рабочую ветку (не мастер) забрать все изменения из мастера. Это можно сделать, выполнив команду:

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

После того как вы разрешите конфликты во всех требуемых местах, нужно отправить это дело коммитом в репозиторий. После разрешения конфликтов можно выполнить слияние веток. Как правило, это делается через интерфейс используемого веб-сервиса (github\gitlab).

Также отдельно стоит упомянуть, что лучшего момента для code review, кроме как во время запроса на слияние (pull\merge request) нет, так как на этом этапе еще можно внести правки, и это никак не отразится на мастер-ветке.

Затем нужно доставить код на продакшен сервер, для этого требуется подключиться по ssh и ввести команду:

Итого наш воркфлоу выглядит так:

1. Получили задачу.

2. Создали ветку.

3. Внедрили ТЗ, протестировали локально, отправили коммит в репозиторий.

4. Сделали git pull origin branch-name на тестовом стенде, протестировали.

5. Создали pull request, произвели код-ревью, залили ветку в master.

6. Git pull origin master на проде.

Еще бывает автодеплой на продакшен. Это когда по какому-то триггеру код из репозитория сам заливается на продакшен. Тема обширная и выходит за рамки этой статьи, поэтому разберем как-нибудь в другой раз. Просто имейте ввиду, что так бывает.

Кстати, в таком случае лучше уточнять порядок работы с репозиторием у его владельца, так как неаккуратное действие (например, коммит в master ветку) может сломать этот механизм.

Данная статья не позиционируется как исчерпывающее руководство по использованию git. Скорее мы хотели подсветить удобство использования полезного инструмента.

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

В нашем рабочем процессе мы придерживаемся системного подхода: создаем отдельные ветки для задач, детально описываем коммиты, проводим code review перед слиянием в master и следим за чистотой репозитория. Такой метод позволяет эффективно управлять кодом, упрощает поддержку проектов и минимизирует риски.

Git не только помогает отслеживать изменения, но и делает работу над проектами прозрачной и предсказуемой. Чем лучше организована работа с ним, тем быстрее можно находить и исправлять ошибки, разрабатывать новые функции, поддерживать стабильность кода и радовать клиентов. Используйте систему контроля версий правильно, и ваша разработка станет более удобной, продуктивной и безопасной.