Merge Request (MR): что это, как создать и процесс ревью

Что такое Merge Request (MR)?

Merge Request (MR) — запрос на интеграцию изменений из одной ветки Git в другую, который инициирует процесс код-ревью и автоматической проверки. В отличие от прямого слияния через консоль, MR создает формальную процедуру: разработчик описывает изменения, назначает ревьюеров, запускает CI/CD и получает обратную связь до применения изменений. Это ключевой элемент GitLab, но аналогичный механизм в GitHub называется Pull Request (PR).

По данным GitLab Documentation, 2026, в GitLab создаётся более 80 миллионов Merge Request ежегодно. Каждый MR содержит четыре основных компонента: описание (description) с контекстом изменений, список коммитов (commits), разницу в коде (diff) и обсуждение (discussion thread). Без одного из этих элементов MR считается неполным.

Merge Request (MR) решает три задачи: предотвращает прямые изменения в защищённых ветках (main, develop), обеспечивает контроль качества через ревью и сохраняет историю обсуждений для будущих разработчиков. В GitLab статус MR отображается в интерфейсе с цветовой индикацией: серый для Draft, оранжевый для ожидания, зелёный для Approved, фиолетовый для Merged и красный для Closed.

Терминология: MR, PR и CR

В разных Git-платформах Merge Request называется по-разному. GitLab использует «Merge Request» (MR), GitHub — «Pull Request» (PR). Аналогия — Change Request (CR) в Gerrit. Все три обозначают один и тот же процесс: запрос на интеграцию изменений через код-ревью. Выбор термина зависит только от платформы, используемой в проекте.

# Создать ветку с изменениями
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# Создать MR можно через UI GitLab/GitHub или CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: в чем разница между GitLab и GitHub

Merge Request в GitLab и Pull Request в GitHub — это функционально одинаковые механизмы с разными названиями. Разница обусловлена историей: GitLab изначально позиционировался как Self-Hosted альтернатива GitHub и выбрал термин «merge request» для процесса слияния. GitHub, запущенный раньше, использовал «pull request» — запрос «потянуть» (pull) изменения в основную ветку.

По данным GitHub Docs, 2024, оба инструмента поддерживают одинаковый набор функций: описание с Markdown, назначение ревьюеров, комментирование конкретных строк кода, статусы проверок и автоматическое слияние при выполнении условий. Различия касаются интерфейса и дополнительных возможностей.

Как создать Merge Request: пошаговая инструкция

Создание Merge Request (MR) начинается с публикации ветки с изменениями в удалённом репозитории. После push в GitLab или GitHub в интерфейсе появляется кнопка «Create Merge Request» или «Compare & Pull Request». Разработчик заполняет описание, указывает target-ветку (обычно develop или main), назначает ревьюеров и прикрепляет метки (labels).

По данным GitLab Documentation, 2025, стандартный MR содержит заголовок до 72 символов, описание с шаблоном (template) и ссылку на задачу (issue). Описание должно отвечать на вопросы: что сделано, почему, как тестировалось. GitLab поддерживает авто-закрытие issue при мерже через ключевые слова Closes, Fixes, Resolves.

# Пример шаблона .gitlab/merge_request_templates/default.md
## What does this MR do?

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

## How to test

1. Запустить ./gradlew test
2. Проверить LoginActivity с тестовым токеном
3. Убедиться, что нет регрессии в AuthManager

## Related issues

Closes #142

Жизненный цикл MR: от Draft до Merged

Merge Request (MR) проходит пять статусов в GitLab. Первый — Draft (черновик), помечается префиксом «Draft:» в заголовке и блокирует слияние. После готовности разработчик убирает Draft, и MR переходит в статус Opened — начинается код-ревью и запускается CI/CD пайплайн.

По данным GitLab Docs, 2024, в статусе Opened ревьюеры просматривают diff, оставляют комментарии и запрашивают изменения через Resolve Threads. Когда все треды закрыты и CI/CD проходит успешно, ответственный разработчик ставит Approve. После этого MR можно смержить кнопкой Merge, либо дождаться автоматического слияния (Auto-merge).

GitLab поддерживает три варианта финального статуса: Merged (успешно влито), Closed (закрыто без слияния, например, при отказе от фичи) и Reopened (повторное открытие после закрытия). Каждый статус логируется в Activity Timeline MR для аудита.

Автоматические статусы и триггеры

GitLab автоматически обновляет статус Merge Request при наступлении событий: при push новых коммитов сбрасываются Approvals, при успешном CI пайплайне статус становится Pipeline passed, при failure — Pipeline failed (мерж блокируется). Можно настроить Auto-merge: MR вливается автоматически после успешного CI и получения всех требуемых аппрувов.

• Draft — черновик, CI запускается, но мерж заблокирован
• Opened — готов к ревью, назначены ревьюеры, пайплайн активен
• Approved — получено необходимое количество аппрувов
• Merged — изменения влиты в target-ветку
• Closed — закрыт без слияния

Правила код-ревью в Merge Request

Код-ревью в Merge Request (MR) — обязательный этап в большинстве коммерческих проектов. По данным исследования SmartBear, 2023, код-ревью с MR сокращает количество дефектов на 30–60% и ускоряет онбординг новых разработчиков. Основное правило — каждый MR проверяет минимум один, а лучше два разработчика, не участвовавших в написании кода.

Проверка MR включает пять критериев: корректность логики, соответствие код-стайлу, покрытие тестами, безопасность и производительность. В GitLab можно настроить Required Approvals — обязательное количество аппрувов перед мержем, например, 2 аппрува для main и 1 для develop.

Обсуждение в MR ведётся в Threads — комментариях к конкретным строкам кода. Каждый тред должен быть resolved (закрыт) до слияния. Для ускорения ревью рекомендуется ограничивать размер MR: 200–400 строк изменений. Согласно данным Google Research (2022), MR объёмом более 400 строк проверяются на 30% менее эффективно.

CI/CD пайплайн в Merge Request

При создании Merge Request (MR) автоматически запускается CI/CD пайплайн. В GitLab это происходит через файл .gitlab-ci.yml, в GitHub — через GitHub Actions workflow. Пайплайн включает сборку проекта (build), прогон модульных тестов (unit tests), линтеры (lint), статический анализ (SAST) и проверку покрытия кода.

По данным GitLab Blog, 2024, статус пайплайна отображается прямо в MR: зелёная галочка (passed), красный крест (failed) или жёлтый круг (running). Если пайплайн упал, GitLab блокирует кнопку Merge до исправления. В настройках можно включить «Merge when pipeline succeeds» — автоматический мерж после успешного пайплайна.

# .gitlab-ci.yml — пример для Android-проекта
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

Методы слияния: Squash, Merge Commit, Fast-Forward

GitLab и GitHub предлагают три метода слияния для Merge Request. Выбор зависит от политики команды и требуемой чистоты истории. Merge Commit — создаёт отдельный коммит слияния, сохраняя всю историю feature-ветки. Squash — объединяет все коммиты ветки в один коммит на target-ветке. Fast-Forward — применяет коммиты линейно без коммита слияния.

По данным GitLab Docs, 2025, Squash предпочтителен для проектов с высокой плотностью коммитов (20+ коммитов в одной feature-ветке). Fast-Forward обязателен для Trunk-Based Development. Merge Commit используется в Git Flow для сохранения семантики ветвления.

• Merge Commit — сохраняет историю, создаёт коммит слияния, подходит для Git Flow
• Squash — объединяет все коммиты в один, чистая история, теряются промежуточные коммиты
• Fast-Forward — линейная история без коммита слияния, обязателен в TBD

Лучшие практики: как писать хороший MR

Качественный Merge Request (MR) сокращает время ревью и снижает количество ошибок. Первое правило — один MR решает одну задачу. Если изменения затрагивают несколько unrelated фич, их нужно разбить на отдельные MR. Второе — заголовок MR должен быть информативным: «Add OAuth2 authentication with Google provider» вместо «Fix stuff» или «Update code».

По данным Google Engineering Practices, 2024, хороший MR содержит описание контекста: почему изменения необходимы, как они тестировались, какие есть риски. Размер MR не должен превышать 400 строк изменений. Если объём больше — задачу нужно декомпозировать на подзадачи. Для документации и тестов исключения допустимы, но с пояснением.

Merge Request (MR) должен включать авто-тесты на новую функциональность. В GitLab можно настроить политику Coverage Check — MR автоматически блокируется, если покрытие кода упало ниже порога (например, 80%). Это гарантирует, что новая функциональность не снижает общее качество проекта.

• Один MR — одна задача: декомпозируйте крупные изменения на несколько маленьких MR
• Описание с шаблоном: используйте .gitlab/merge_request_templates для единообразия
• Размер до 400 строк: большие MR проверяются медленнее и с большим числом ошибок
• Тесты обязательны: новые фичи должны покрываться модульными тестами

Шаблоны описания MR

GitLab поддерживает шаблоны Merge Request через файлы .gitlab/merge_request_templates/. Шаблон включает секции: что сделано, как тестировать, связанные задачи и чек-лист. Использование шаблонов ускоряет создание MR и гарантирует, что разработчики не забудут указать важную информацию. В описании MR обязательно указываются связанные issue (Closes #N) для авто-закрытия задач при мерже.