315 слов | 2 минуты

Git Workflow — работа в команде

Описание рабочего процесса с Git: как создавать ветки под задачи, оформлять коммиты, создавать Merge Request и передавать код на проверку.

Работа с ветками

Для каждой задачи создаётся отдельная ветка. Перед созданием необходимо переключиться на main и получить последние изменения:

git checkout main
git pull origin main

Важно: без актуального main в ветке окажется устаревший код, и при создании Merge Request возникнут конфликты.

feature/xxxx — ветки для работы над задачами, где xxxx — номер задачи:

# находясь на ветке main
git checkout -b feature/244000

hotfix/xxxx-x — ветки для исправления ошибок, обнаруженных без постановки задачи:

# находясь на ветке main
git checkout -b hotfix/244000-1
git checkout -b hotfix/244000-2

Зависимые задачи

Если задачи связаны (редактируют одни и те же файлы), их выполняют последовательно:

1. Завершить работу над первой задачей (например, 244001).
2. Слить ветку задачи 244001 с main.
3. Создать ветку для следующей задачи из обновлённого main.

Оформление коммитов

Каждый коммит начинается с номера задачи. Заголовок отвечает на вопрос «Что делает этот коммит?»:

244001 изменяет время кэширования компонентов на странице новостей
244002 исправляет ошибку сортировки товаров в каталоге
244003 добавляет логирование ошибок в компоненте stmd:order.ajax

Правила:

• Только строчные буквы после номера задачи
• Без тире, двоеточий и пунктуации после номера
• Тело коммита (детали) — в свободной форме после пустой строки

Плохие примеры: 244001 исправлен баг, 244002 правки, 244003 поработал над компонентом

Для hotfix без номера задачи:

исправляет ошибку с кэшированием в компоненте stmd:gallery.video

Работа с компонентами Bitrix

При копировании шаблона компонента сначала делается коммит с копией, затем — коммиты с правками:

244001 копирует шаблон .default у bitrix:catalog.section в новый шаблон squared
244001 изменяет разметку и стили шаблона squared у bitrix:catalog.section

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

git push origin feature/xxxx

Merge Requests

Ветка main защищена — прямой push в неё невозможен. Для слияния создаётся Merge Request.

1. После git push перейдите в GitLab → Merge Requests → New Merge Request.
2. Укажите осмысленный заголовок, начинающийся с номера задачи.
3. В поле Assignee укажите автора запроса.
4. В поле Reviewer выберите Release Manager.
5. При необходимости укажите Milestone и проставьте теги.
6. Нажмите Create merge request.

Если задача объёмная (например, новый дизайн) — MR оформляется в ветку develop.

Статус WIP: если задача не завершена, добавьте WIP: в начало заголовка MR или нажмите Start the title with WIP:. Перед передачей на релиз статус необходимо снять.

По завершении работы:

1. Убедитесь, что статус WIP снят.
2. Заполните поле Отчёт в Planfix.
3. Переведите задачу в статус Code Review.

Примечание: Ответственный за релиз — переходящая роль; сегодня её может исполнять один разработчик, завтра другой.