01 · Процессы и командная работа1.2 · Git и командная разработка1.2.2лёгкий

Pull Request, code review и защита main

Зачем это нужно

Commit в свою ветку — личное дело. Merge в main — ответственность перед всей командой: завтра этот код пойдёт в продакшен. Pull Request (PR, в GitLab — Merge Request, MR) — механизм, который вставляет паузу между «я написал» и «это стало частью продукта». Code review ловит баги, улучшает читаемость и распространяет знания в команде.

Для студента PR — привычка, которую оценят на первой же стажировке. «Пушил сразу в main» — красный флаг на code review собеседования.

Основные идеи

Pull Request — запрос на слияние вашей ветки в целевую (обычно main). PR содержит:

  • diff изменений;

  • описание: что сделано, ссылка на Jira-task, как тестировали;

  • список ревьюеров;

  • результаты CI (тесты, линтер).

Code review — правила хорошего тона:

  • PR должен быть небольшим (< 400 строк — ориентир; ML-ноутбук на 2000 строк — разбить).

  • Автор сам проверяет diff перед отправкой.

  • Ревьюер комментирует код, не человека: «здесь возможен деление на ноль», не «ты плохо написал».

  • Каждый комментарий — resolved или ответ автором.

  • Merge только после approve (обычно 1–2 approves) и зелёного CI.

Защита main (branch protection):

  • Прямой push в main запрещён.

  • Merge только через PR.

  • CI должен пройти.

  • Ветка должна быть актуальна относительно main.

Настраивает DevOps в GitHub/GitLab; разработчик просто следует правилам.

Merge vs Rebase:

  • Merge — создаёт merge-commit, сохраняет историю веток. Просто и безопасно для команд.

  • Rebase — «переписывает» ваши commit поверх актуального main, история линейная. Требует осторожности: не rebase уже запушенных общих веток.

Для курса: перед PR делайте git pull origin main (или rebase на main), решайте конфликты локально.

Conventional Commits — соглашение о формате сообщений:

feat: add LightGBM training pipeline fix: handle missing values in inference docs: update runbook for model rollback chore: bump scikit-learn to 1.4

Префиксы помогают автоматически генерировать changelog и семантически версионировать релизы (feat → minor, fix → patch).

Как это выглядит на практике

MLE открывает PR «feat: batch inference endpoint» (Jira ML-67):

`

Summary

  • POST /predict/batch принимает CSV до 10k rows
  • Model loaded from S3 at startup

Test plan

  • unit tests pass
  • manual curl with sample.csv
  • load test — отдельная Story ML-70

Jira

ML-67 `

Backend-ревьюер оставляет комментарий: «добавь timeout 30s на загрузку модели». MLE исправляет, CI зелёный, approve, squash merge в main.

Confluence Service Page обновляется в отдельном PR docs: add /predict/batch to API section.

Что сделать после занятия

  • Откройте PR (или симулируйте описание) для одной ветки из предыдущего урока — Summary + Test plan + Jira link.

  • Перепишите 3 своих commit message в формате Conventional Commits.

  • Опишите, что произойдёт при merge без прохождения CI, если main защищён.

Официальные материалы