← назад к разделу

Pull request (в GitLab — merge request) — это предложение влить вашу ветку в основную, оформленное на сервере: с описанием, обсуждением, автопроверками и кнопкой слияния. Вокруг PR построен командный контроль качества: чужие глаза (код-ревью) и автоматика (CI-конвейер) смотрят на изменение до того, как оно попадёт в общий код.

Жизненный цикл PR

  1. Запушили ветку → открыли PR «моя ветка → main».
  2. Автоматика гоняет сборку, тесты, линтеры; коллеги читают код и оставляют замечания.
  3. Вы дорабатываете: новые коммиты в ту же ветку автоматически попадают в PR.
  4. Одобрение (approve) → слияние → ветка удаляется.

Ещё не готово, но нужен ранний взгляд — откройте draft PR: обсуждение уже возможно, кнопка слияния заблокирована.

Оформление: уважение к времени читателя

Ревьюеру предстоит понять ваше изменение без вашего контекста. Помогите:

  • Заголовок — что делает PR, в одну строку (часто с номером задачи): «PROJ-142: экспорт заказов в CSV».
  • Описание — что и зачем изменено, как проверить; скриншоты для UI. Ссылку на задачу — обязательно.
  • Размер — главный фактор качества ревью. PR на 200 строк читают внимательно, на 2000 — «одобряют глазами». Большую задачу режьте на цепочку маленьких PR.
  • Самопроверка: перед назначением ревьюеров сами пройдитесь по вкладке изменений. Забытый отладочный вывод, закомменченный код, случайный файл — дешевле поймать самому.

Как проходить ревью

Замечания к коду — не оценка вас; это второй контур того же контроля качества, что и тесты. Рабочие привычки:

  • Отвечайте на каждое замечание: поправили — «сделано» (и коммит), не согласны — аргументируйте. Молча проигнорированное замечание = потерянное доверие.
  • Не согласны — обсуждайте, а не продавливайте. Два раунда переписки без сближения — повод созвониться: голосом решается за минуты.
  • Доработки — новыми коммитами, не перезаписью: ревьюеру важно видеть, что изменилось после его замечаний. Прибраться в истории можно перед самым слиянием.
  • Смотрите на зелёность конвейера до ревьюеров: просить людей читать код, который не собирается, — невежливо.

Ревью в обратную сторону — тоже навык: комментируйте код, а не автора («здесь потеряется ошибка», а не «ты потерял ошибку»), предлагайте, а не приказывайте, отмечайте хорошее.

Три способа слить

Кнопка слияния обычно предлагает выбор:

  • Merge commit — вся история ветки вливается как есть + merge-коммит. Полная летопись, но main зарастает мелкими «wip»-коммитами.
  • Squash and merge — все коммиты ветки схлопываются в один аккуратный. Main остаётся чистым: одна задача = один коммит. Самый частый выбор команд.
  • Rebase and merge — коммиты ветки переносятся в main по одному, без merge-коммита: прямая линия истории.

Что выбирать — командное соглашение из модели ветвления. Практическое следствие squash: не полируйте промежуточные коммиты ветки сверх разумного — в main всё равно уедет один.

Коротко

  • PR = ветка + описание + обсуждение + автопроверки + кнопка слияния. Draft — для раннего взгляда.
  • Маленький PR с внятным описанием «что и зачем» — половина качества ревью. Самопроверка диффа перед назначением ревьюеров.
  • На замечания отвечать все; доработки — новыми коммитами; споры дольше двух раундов — голосом.
  • Слияние: merge (летопись), squash (задача = коммит, чаще всего), rebase (прямая линия) — по соглашению команды.

Что почитать дальше

  • Модели ветвления — как PR встраивается в процесс команды.
  • Rebase и cherry-pick — приборка истории ветки перед слиянием.
  • CI/CD-конвейер — автопроверки, которые гоняются на каждый PR.