Create merge request GitLab: полный гайд с шаблонами и автоматизацией

Два часа ночи. Закончил фичу, хочу спать. Открываю GitLab, чтобы создать merge request — и в очередной раз вручную заполняю поля, пишу описание, назначаю ревьюе

Два часа ночи. Закончил фичу, хочу спать. Открываю GitLab, чтобы создать merge request — и в очередной раз вручную заполняю поля, пишу описание, назначаю ревьюера. Знакомо?

Со временем это раздражает. Поэтому разобрался, как сделать процесс максимально безболезненным — и чтобы MR были качественными по умолчанию. Расскажу про все способы создать merge request в GitLab, шаблоны, автоматизацию и пару фишек, про которые не все знают.

Как создать merge request в GitLab: три способа

Самый очевидный — через UI. Заходишь в проект, переключаешься на ветку, видишь жёлтый баннер "Create merge request". Кликаешь, заполняешь форму, готово. Работает. Но есть нюансы.

Второй способ — через CLI. Если работаешь из терминала, лишний раз браузер открывать лень. GitLab не умеет в это из коробки, но есть glab:

# Установка (macOS)
brew install glab

# Авторизация
glab auth login

# Создание MR из текущей ветки
glab mr create --title "Добавил обработку ошибок в API" --description "Описание изменений..."

Третий способ — push с опцией. Самый быстрый, если нужно создать MR прямо сейчас:

git push -o merge_request.create origin feature/new-api

GitLab автоматически создаст MR из вашей ветки в дефолтную. Заголовок возьмёт из последнего коммита. Если ветка называется feature/payment-processing, получится MR с заголовком из коммита.

Можно сразу назначить ревьюера и добавить лейблы:

git push -o merge_request.create \
         -o merge_request.assign="username" \
         -o merge_request.label="backend,review-needed" \
         origin feature/new-api

Честно? Я пользуюсь всеми тремя способами. UI — когда нужно подробно описать изменения и добавить скриншоты. CLI — для быстрых правок. Push options — когда точно знаю, что ревью будет простым.

GitLab merge request template: настраиваем один раз

По моему опыту, 80% merge request описаний — это или пустое поле, или "поправил баг". Потом ревьюер гадает, что именно изменилось и зачем. Шаблоны решают эту проблему.

Создайте в корне репозитория папку .gitlab/merge_request_templates/. Внутри — YAML или MD файлы с шаблонами:

<!-- .gitlab/merge_request_templates/Feature.md -->
## Что сделано

[Краткое описание изменений]

## Почему так

[Обоснование технических решений]

## Как тестировать

1. [Шаг 1]
2. [Шаг 2]

## Чек-лист

- [ ] Добавил тесты
- [ ] Обновил документацию
- [ ] Проверил на staging

Теперь при создании MR в выпадающем списке "Choose a template" появится ваш шаблон. Команда перестала писать "поправил баг" и начала заполнять структуру.

Можно сделать несколько шаблонов под разные типы изменений: Feature, Bugfix, Refactoring, Documentation. На одном проекте мы дошли до 6 шаблонов — и это оказалось удобнее, чем один универсальный.

Close merge request GitLab: что это и чем отличается от delete

Тут часто путаются. Close merge request — это закрытие без слияния. Ветка остаётся, MR уходит в архив. Потом можно вернуть, если передумали.

Удалить MR нельзя. GitLab не даёт эту опцию — история есть история. Можно только закрыть.

Когда close имеет смысл:

Передумали merging после ревью — нашли фундаментальные проблемы
Фича отменена бизнесом
Дубликат другого MR
Решили сделать иначе в отдельной ветке

Как закрыть merge request в GitLab:

# Через CLI
glab mr close 42

# Через API
curl --request PUT \
  --header "PRIVATE-TOKEN: $TOKEN" \
  "https://gitlab.com/api/v4/projects/$PROJECT_ID/merge_requests/42" \
  --data "state_event=close"

В UI — просто кнопка "Close merge request" внизу MR. Ничего сложного.

Если нужно снова открыть — там же кнопка "Reopen". Ветка на месте, дискуссия сохраняется, можно продолжить работу.

Как отменить merge request GitLab, если уже нажал Merge

Ситуация страшнее. Вмерджил ветку, CI упал, продакшн лёг. Что делать?

Первое — не паниковать. Второе — есть варианты.

Если ещё не запушили изменения дальше (например, в main):

# Откат коммита merge
git revert -m 1 HEAD
git push origin main

Флаг -m 1 указывает, какой родитель взять за основу. При merge коммите два родителя — берём первый, то есть состояние до merge.

Если включён "Squash commits when merge request is accepted", будет один коммит. Тогда просто:

git revert HEAD
git push origin main

В GitLab есть кнопка "Revert" прямо в интерфейсе merged MR. Она создаст новую ветку с revert-коммитом. Удобно, если не хочешь лезть в терминал.

Но лучше до этого не доходить. Настроить protected branches, требовать одобрения, настроить CI — об этом дальше.

Автоматизация: линтеры, CI/CD и code review

Хороший merge request должен проходить проверки автоматически. Ручной review — для логики и архитектуры, а не для поиска забытых console.log.

Базовый .gitlab-ci.yml для проверки MR:

stages:
  - lint
  - test
  - review

lint:
  stage: lint
  script:
    - pip install ruff
    - ruff check .
  rules:
    - if: $CI_MERGE_REQUEST_IID

test:
  stage: test
  script:
    - pytest tests/
  rules:
    - if: $CI_MERGE_REQUEST_IID

Правило if: $CI_MERGE_REQUEST_IID запускает джобу только для merge request. Для обычных пушей в ветки — не тратим ресурсы.

Теперь про review. Можно интегрировать статический анализ — SonarQube, CodeClimate. Но настройка долгая, отдельный сервер нужен. Для быстрого старта есть AI-инструменты.

Я недавно подключил Distiq к нескольким проектам. Это российский сервис для автоматического code review. Ставишь webhook на merge request — бот анализирует код и пишет инлайн-комментарии. Находит баги, уязвимости, проблемы с производительностью. Поддерживает Python, JavaScript, Go, Java, PHP — основные наши стеки.

Подключается за пару минут: регистрируешь репозиторий, добавляешь webhook в GitLab, всё. На каждый MR получаешь автоматический review. Не заменяет человека, но отсеивает явно плохой код. Меньше времени тратишь на поиск глупых ошибок, больше — на интересную часть review.

Практические советы из опыта

Настройте squash commits. Когда вмердживаешь ветку с 47 коммитами "fix", "wip", "fix again" — это боль. В GitLab можно включить squash по умолчанию в настройках проекта. Получится один чистый коммит с нормальным описанием.

Требуйте аппрувы. В Settings → Merge requests можно указать минимальное количество одобрений. Для main ветки я обычно ставлю минимум 1 аппрув. Для critical систем — 2.

Используйте draft MR. Префикс Draft: или WIP: в заголовке блокирует случайный merge. Пишешь код, ревьюер смотрит, но никто не вмерджит, пока не уберёшь префикс.

# Создать draft MR
glab mr create --draft --title "Draft: Рефакторинг платежей"

Подписывайтесь на MR. Не только на те, где вы автор или ревьюер. Можно подписаться на все MR в проекте или только с определёнными лейблами. Так не пропустите важные изменения в смежных модулях.

Создание merge request в GitLab — не rocket science. Но настроить процесс один раз — и забыть о рутине — стоит того. Шаблоны, автоматизация, правильные привычки. Экономишь по 10-15 минут на каждом MR. За месяц набирается несколько часов. Лучше потратить их на что-то интересное.