Merge request

Merge request#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. Система сама предложит создать MR/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.
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 проекта.

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

Содержание