1.2.2 · блок 1

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
- [x] unit tests pass
- [x] 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 защищён.

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

Открыть интерактивную версию