Десять лет назад я думал, что MR — это просто нажать кнопку и ждать аппрува. Наивный. За годы в Яндексе и стартапах я насмотрелся на всё: от MR на 5000 строк без описания до "fix bug" в заголовке, где баг — это вообще другая фича. И вот что я понял: правильно открытый merge request экономит часы ревью и спасает нервы команды.
Если вы гуглите "merge request gitlab как открыть" — вы по адресу. Но я расскажу не только про кнопки. Расскажу про процесс, который работает в реальных командах.
Базовый сценарий: открываем MR за 5 минут
Предположим, у вас уже есть репозиторий в GitLab и права разработчика. Если нет — сначала создайте проект, это тривиально.
Шаг 1. Создаём ветку.
git checkout main
git pull origin main
git checkout -b feature/add-login-page
Всегда стартуйте от свежего main. Или master, или develop — зависит от вашей модели ветвления. Смысл один: не создавайте ветку от двухнедельной версии, потом намучаетесь с конфликтами.
Шаг 2. Делаем изменения и пушим.
# ... правите код ...
git add .
git commit -m "Add login page with validation"
git push origin feature/add-login-page
При первом пуше GitLab сам подскажет ссылку на создание MR. Удобно.
Шаг 3. Открываем merge request через UI.
Идёте в ваш проект → Merge Requests → New merge request. Выбираете source branch (ваша ветка) и target branch (куда мержите, обычно main).
Дальше заполняете:
- Title — что делает этот MR. Не "fix" и не "update". А конкретно: "Add OAuth2 login via Google".
- Description — зачем, что меняется, как тестировать. Это важно.
- Assignee — кто ревьювит.
- Reviewer — опционально, если у вас раздельные роли.
- Squash commits — галочка, если хотите схлопнуть все коммиты в один при мерже. Лично я всегда ставлю.
Жмёте Create merge request. Готово.
Но это база. Давайте про то, как делать это правильно.
Через CLI: для тех, кто не любит переключаться на браузер
Есть способ быстрее. Если вы работаете в терминале и не хотите прыгать в UI — GitLab CLI ваш друг.
Ставите glab:
# macOS
brew install glab
# Linux
curl -s https://raw.githubusercontent.com/profclems/glab/trunk/scripts/install.sh | sh
Авторизация:
glab auth login
Теперь создаёте MR прямо из терминала:
glab mr create --title "Add OAuth2 login via Google" \
--description "## Changes
- Added Google OAuth2 integration
- Created login page component
- Added unit tests
## How to test
1. Run \`npm install\`
2. Set GOOGLE_CLIENT_ID in .env
3. Navigate to /login" \
--assignee @me \
--target-branch main
Команда вернёт ссылку на созданный MR. Всё, вы в потоке, не отвлекались на браузер.
Есть ещё вариант с GitLab API, если вы автоматизируете:
curl --request POST \
--header "PRIVATE-TOKEN: your-token" \
"https://gitlab.com/api/v4/projects/your-project-id/merge_requests" \
--data "source_branch=feature/add-login" \
--data "target_branch=main" \
--data "title=Add OAuth2 login"
Но это уже для скриптов. В повседневной работе glab удобнее.
Шаблоны MR: экономим время на описании
Знаете, что бесит? Каждый раз писать одно и то же в описании MR. "Как тестировать", "что изменилось", "чек-лист". Решение — шаблоны.
Создайте файл .gitlab/merge_request_templates/Default.md в корне репозитория:
## What does this MR do?
<!-- Краткое описание изменений -->
## Why is this change needed?
<!-- Контекст: проблема, которую решаете -->
## How to test
<!-- Пошаговая инструкция для ревьюера -->
## Checklist
- [ ] Добавил тесты
- [ ] Обновил документацию
- [ ] Проверил локально
- [ ] Нет warnings в CI
Теперь при создании MR GitLab предложит выбрать шаблон. Выбираете — и структура готова.
Можно сделать несколько шаблонов под разные типы изменений: багфикс, фича, рефакторинг. У нас в одном проекте было 5 шаблонов, и это сократило время на оформление MR где-то на 40%.
Ещё лайфхак: добавьте в шаблон ссылки на связанные тикеты, метки по умолчанию. Мелочи, но в масштабе команды экономят часы.
CI/CD и merge requests: связываем всё воедино
MR сам по себе — это просто запрос на слияние кода. Магия начинается, когда подключаете CI/CD.
В GitLab есть концепция pipelines for merge requests. Пайплайн запускается только когда открыт MR, и его статус виден прямо в интерфейсе.
Базовый .gitlab-ci.yml:
stages:
- test
- build
test:
stage: test
script:
- npm ci
- npm run test
rules:
- if: $CI_MERGE_REQUEST_IID
- if: $CI_COMMIT_BRANCH == "main"
build:
stage: build
script:
- npm run build
rules:
- if: $CI_MERGE_REQUEST_IID
Ключевое тут — rules с $CI_MERGE_REQUEST_IID. Это значит: запускать джобу только для MR. Не для каждого коммита в ветку, а именно когда MR открыт.
Зачем? Экономия ресурсов CI и чёткая связь: пайплайн зелёный — MR можно мержить. Красный — сначала исправь.
Добавьте ещёMerge result pipelines — это когда GitLab пробует смержить вашу ветку с target и прогнать тесты на результате. Поймает проблемы интеграции до того, как они попадут в main.
workflow:
rules:
- if: $CI_MERGE_REQUEST_EVENT_TYPE == "merge_train"
- if: $CI_MERGE_REQUEST_IID
- if: $CI_COMMIT_BRANCH == "main"
Это уже продвинутый уровень, merge trains. Но если у вас большая команда и частые мержи — это спасёт от "я замержил, и всё сломалось".
Автоматическая проверка кода: пусть AI делает рутину
Самое больное в ревью — ловить очевидные ошибки. Забытый console.log, захардкоженный пароль, неиспользуемая переменная. Ревьюер устаёт на пятом MR за день и пропускает.
Решение — автоматизировать базовую проверку. ESLint, Prettier, SonarQube — классика. Но есть вариант интереснее: AI-бот, который сам смотрит код и пишет замечания.
Мы в команде подключили Distiq. Это российский сервис, который анализирует каждый MR и оставляет инлайн-комментарии. Находит баги, уязвимости, проблемы с производительностью. Поддерживает Python, JavaScript, TypeScript, Java, Go, PHP — у нас TypeScript-проект, завелся за минуту.
Интеграция элементарная: добавляете webhook в настройки GitLab, и всё. Бот сам появляется в каждом MR. Первые дни было непривычно: приходит "робот" и указывает на проблемы. Но потом привыкли — он ловит то, что уставший ревьюер пропустит.
В целом, merge request в GitLab открывается за пару минут. Но за этими минутами стоит процесс, который либо работает на команду, либо против. Настроенные шаблоны, CI-пайплайны, автоматическая проверка кода — это не избыточность, а инвестиция в скорость. Проверено на десяти годах разработки.