Запросы на слияние (merge request, MR)

Подготовка

• Ответвляйтесь от актуальной целевой ветки (как правило, основной ветки разработки, о которой договорились в команде).
• Держите MR узким по смыслу: одна тема или тесно связанный набор правок; несвязанные изменения усложняют ревью и откат.
• Перед открытием MR убедитесь, что сборка и тесты проходят локально (или в вашем fork CI), а сообщения коммитов соответствуют CONTRIBUTING.md.
• Если в репозитории есть обязательные артефакты от генераторов (например, матрица CI из скрипта), сгенерируйте и включите их в тот же MR, а не отдельным коммитом «потом».

Создание MR: порядок действий

1. Запушьте ветку в общий remote (или откройте MR из fork — по правилам вашего GitLab).
2. Создайте MR в GitLab и сразу заполните:
   • заголовок — кратко и по сути (на английском, в духе Conventional Commits, если это отражает суть изменений);
   • описание — что сделано и зачем, как проверить, ссылки на задачи (Closes #…, See …), скриншоты при изменении UI/поведения;
   • целевую ветку — ту, в которую должны попасть изменения.
3. Пока работа не готова к ревью, используйте черновик (Draft / «В работе»), чтобы не тратить время проверяющих.
4. Когда MR готов к проверке: снимите черновик, назначьте проверяющего (reviewers) и при необходимости ответственного за слияние (assignee) — по договоренности команды (см. ниже).
5. Проставьте метки (labels) и связь с issue/epic, если принято в проекте.

Назначение проверяющего и ответственного

• Проверяющий (reviewer) — тот, кто обязан дать ревью по содержанию: корректность, соответствие стилю и архитектуре, риски.
• Ответственный (assignee) — часто автор MR или человек, который доведет MR до merge (исправления, ответы в обсуждениях); в командах по-разному: зафиксируйте локально, кто ставится assignee.
• Назначайте людей с компетенцией в затронутой области; при сомнении — владельца подсистемы или того, кого указала команда.
• Если проверяющий не может взять MR (загрузка, отпуск), он должен переназначить или явно отписаться, чтобы автор мог выбрать другого.
• Не добавляйте лишних проверяющих «для галочки» — у каждого должна быть роль (основной ревьюер, опциональный эксперт по узкой теме).

Правила ревью

Проверяющий оценивает:

• Соответствие задаче и отсутствие лишних изменений.
• Корректность и читаемость кода, граничные случаи, ошибки.
• Тесты — покрытие нового поведения, не ломается ли существующее.
• Документацию и комментарии, где поведение неочевидно.
• CI — пайплайн зеленый или согласованные исключения.

Замечания оформляйте в обсуждениях к строкам или общим комментарием; формулировки конструктивные, с предлагаемой альтернативой, где уместно. Автор отвечает на каждое замечание: исправление в коде, объяснение или открытый вопрос.

Запрос на доработку (Changes requested)

Если проверяющий запрашивает изменения:

• Автор вносит правки в ту же ветку и пушит новые коммиты (или переписывает историю — только если команда договорилась и это не мешает ревьюеру).
• После исправления отметьте обсуждения как решенные (Resolve), когда проблема снята, или оставьте комментарий, почему не применили предложение.
• Запросите повторное ревью у того же проверяющего после существенных правок.

Не закрывайте MR из-за доработок без необходимости — лучше обновить ветку.

Одобрение (Approve)

• Одобрение означает: при текущем состоянии ветки проверяющий не блокирует слияние (с учетом политики проекта: может потребоваться несколько одобрений).
• Автор не мержит сам до зеленого CI и выполнения правил проекта, если так задано.

Вливание (merge)

• Сливайте, когда: CI успешен, требуемые одобрения получены, все обязательные обсуждения закрыты или сняты блокирующие вопросы.
• Кто нажимает Merge — по правилам команды: автор после апрува или только maintainer; при сомнении уточните у мейнтейнеров.

После слияния

• Удаление ветки в GitLab после merge рекомендуется для типичных feature-веток, чтобы не копить мусор в remote.
• Не удаляйте долгоживущие ветки (release trains, shared integration branches) и ветки, на которые еще ссылаются открытые MR или локальные клоны команды — уточните у команды.

Краткий чеклист

Другие языки: English