Перейти к основному содержанию
`Ctrl`+`K`

# Merge request

Merge Request (MR) — запрос на слияние изменений из одной ветки репозитория в другую. Это ключевой механизм в системах контроля версий (таких как GitLab), предназначенный для проверки, обсуждения и интеграции кода перед его включением в основную ветку проекта.

Порядок выполнения Merge Request от разработчика:

1. Создает отдельную ветку для задачи (фичи, исправления).

2. Формирует запрос на слияние этой ветки с целевой (например, main, develop).

3. Организует проверку кода (code review) командой.

4. Вносит правки на основе комментариев.

После одобрения и успешных автоматических проверок (тесты, сборка) изменения сливаются в целевую ветку.

## Зачем он нужен

- Контроль качества: главная цель — коллективный просмотр кода (code review). Другие разработчики могут найти ошибки, предложить более оптимальные решения и убедиться, что код соответствует стандартам проекта.

- Обмен знаниями: команда видит, какие изменения вносятся в кодовую базу, и узнает о новых функциях или исправлениях.

- Обсуждение: платформа для обсуждения архитектурных решений прямо в контексте кода.

- Автоматизированные проверки: запуск CI/CD пайплайна (тесты, линтеры, сборка) гарантирует, что изменения не сломают сборку или функционал.

- Документирование: история всех обсуждений и утверждений изменений сохраняется и привязана к коду.

## Процесс работы с Merge Request

### Шаг 1: Подготовка перед созданием MR

- Локально: Убедитесь, что ваша ветка готова к мержу.

- Запушите ветку: Отправьте свою ветку в удаленный репозиторий.

### Шаг 2: Создание Merge Request

1. Перейдите на страницу вашего репозитория на GitLab/GitHub.

2. Система сама предложит создать MR для недавно запушенной ветки.

3. Заполните форму:

   - Title: заголовок MR.

   - Description: описание. Что было сделано? Зачем? Какие ключевые изменения? Прикрепите скриншоты, если это UI.

   - Assignee: назначьте ответственного (тимлида или коллегу) на ревью.

   - Reviewers: укажите нужных людей для ревью.

   - Labels: добавьте соответствующие метки (bug, feature, frontend, backend).

### Шаг 3: Ревью и процесс обсуждения

1. Ревьюверы изучат ваш код, оставят комментарии (общие или привязанные к конкретной строке кода). Комментарии бывают:

   - Comment: Просто вопрос или замечание.

   - Approval: Одобрение изменений.

2. Если нужны правки:

   1. Внесите правки локально в ту же ветку.

   2. Сделайте коммит (с понятным сообщением, например, fix: Учтены правки ревью #issue 123456T).

   3. Запушьте изменения. MR обновится автоматически.

3. Обсуждение продолжается до тех пор, пока все правки не будут учтены и не будет получено одобрение (approve).

### Шаг 4: Слияние (Merge)

После получения одобрений и успешного прохождения всех CI-проверок (зеленая галочка) вы можете выполнить слияние нажав кнопку Merge.

- Delete source branch: автоматическое удаление ветки, из которой был создан Merge Request, сразу после успешного слияния. Это помогает поддерживать репозиторий в чистоте, избавляя его от устаревших веток. Рекомендуется включать эту опцию всегда, если вы не планируете продолжать работу в этой ветке.

- Squash commits: объединяет все коммиты из вашей ветки в один новый коммит перед слиянием в целевую ветку. Это упрощает историю проекта, делая ее линейной и легко читаемой, и скрывает промежуточные, технические или «черновые» коммиты. Идеально подходит для задач, где было сделано множество мелких коммитов.

- Edit commit message: редактирование сообщения финального коммита, который будет создан при слиянии. Если вы используете «Squash commits», это сообщение станет описанием всего объединенного изменения. Если нет — оно будет применено к коммиту слияния. Рекомендуется включать эту опцию при использовании «Squash commits».

### Идеальный Merge Request

- Содержит небольшие, логически завершенные изменения. (Большие MR сложно ревьюить).

- Имеет четкий заголовок и описание, объясняющее мотивацию изменений.

- Вся история коммитов в ветке тоже написана по правилам.

- Связан с задачей в issue tracker (например, `Jira`, `YouTrack`).

- Включает в себя тесты для нового функционала или исправлений.

- Не ломает существующие тесты (CI пайплайн успешен).

- Не содержит закомментированного «мусорного» кода.

- Соответствует code style проекта.

- Следование этому процессу делает разработку предсказуемой, качественной и командной.