Pull Request и code review

Pull Request (PR) - или Merge Request (MR) в GitLab - это механизм предложить изменения из одной ветки в другую с обсуждением, автоматическими проверками и ревью.

На уровне Git ты уже умеешь создать ветку, сделать коммиты, запушить её и слить через merge. PR добавляет командный процесс вокруг этих действий: кто проверяет изменения, какие тесты должны пройти, какие правила защищают main, как оставить комментарии и как зафиксировать решение.

Зачем нужен PR

Без PR разработчик может запушить напрямую в main, и изменения сразу станут частью основной истории. Это быстро, но рискованно: ошибка в конфиге, секрет в файле, сломанный тест или неудачный Dockerfile могут попасть дальше в CI/CD и production.

С PR процесс выглядит иначе:

Разработчик создаёт ветку feature/login.
Делает изменения и коммиты.
Пушит ветку на remote.
Открывает PR: "прошу слить feature/login в main".
CI запускает проверки.
Коллеги смотрят diff и оставляют комментарии.
После исправлений и одобрения ветка вливается в main.

PR - это не просто кнопка merge. Это место, где команда синхронизирует понимание изменения.

Protected branches

На большинстве проектов main или master защищены.

Типичные правила:

прямой push в main запрещён;
требуется минимум 1-2 approval;
должны пройти CI/CD проверки;
ветка должна быть актуальна относительно main;
force push запрещён;
удаление protected branch запрещено.

Эти ограничения нужны не для бюрократии, а для защиты общей истории. main обычно является источником деплоя, релизов или production-сборок, поэтому случайные изменения там обходятся дорого.

Типичный рабочий процесс

# создать ветку от актуального main
git switch main
git pull origin main
git switch -c feature/add-login

# работа, коммиты
git add .
git commit -m "Add login form"
git commit -m "Add login API endpoint"

# отправить ветку
git push -u origin feature/add-login

Дальше PR создаётся в интерфейсе GitHub/GitLab. После замечаний ревьюера ты продолжаешь работать в той же ветке:

# правки после review
git add .
git commit -m "Address login review comments"
git push

PR обновится автоматически, потому что он связан с веткой feature/add-login.

После merge:

git switch main
git pull origin main
git branch -d feature/add-login

Если remote-ветка больше не нужна, её удаляют в интерфейсе или командой:

git push origin --delete feature/add-login

Что должен содержать хороший PR

Хороший PR помогает ревьюеру быстро понять изменение.

Обычно в описании есть:

что изменилось;
зачем это нужно;
как проверить;
какие риски есть;
ссылки на задачу, инцидент или тикет;
скриншоты или логи, если это UI/операционная задача.

Плохое описание: fix.

Лучше:

Добавлен healthcheck endpoint /healthz для Kubernetes readinessProbe.

Проверка:
- curl localhost:8080/healthz возвращает 200
- docker compose test проходит

Риск:
- endpoint не требует авторизации, но не раскрывает чувствительные данные

DevOps-изменения особенно важно описывать проверяемо: какой сервис затронут, как откатить, какие метрики или логи смотреть после деплоя.

Code Review: что проверяют

На ревью смотрят не только стиль кода.

Типичные вопросы:

изменение делает то, что заявлено в PR?
нет ли лишних файлов в diff?
не попали ли секреты, .env, токены, приватные ключи?
есть ли тесты или понятная ручная проверка?
не ломает ли изменение совместимость;
не меняет ли инфраструктуру шире, чем нужно;
понятны ли имена, структура и сообщения коммитов;
можно ли безопасно откатить изменение?

Для DevOps PR часто отдельно проверяют:

корректность Dockerfile и .dockerignore;
переменные окружения и секреты;
Kubernetes probes, resources, labels;
Terraform plan;
миграции и порядок деплоя;
rollback-план.

Как давать комментарии

Хороший комментарий конкретен и проверяем.

Плохо: плохо.

Лучше:

BLOCKER: здесь токен попадёт в git history. Нужно убрать файл из индекса через git rm --cached и перенести значение в CI/CD variables.

Полезно отделять обязательные правки от мелких замечаний:

BLOCKER: - без исправления merge нельзя делать;
suggestion: - предложение улучшить;
nit: - мелочь, не блокирует merge;
question: - нужно уточнение.

Ревью должно улучшать изменение, а не угадывать намерения автора. Если логика непонятна, лучше попросить объяснение или тест, чем молча пропустить.

Как отвечать на review

Нормальный цикл PR:

review -> правки -> push -> повторная проверка -> approve -> merge

Если замечание справедливое, исправь его отдельным коммитом или обнови существующий коммит, в зависимости от правил команды.

Если ты не согласен, отвечай технически:

Оставил текущий вариант, потому что readinessProbe должна проверять только HTTP-слой. Проверка подключения к БД уже есть в startupProbe, иначе краткий сбой БД будет перезапускать pod.

Такие ответы полезны: они превращают PR в документацию решения.

Merge strategies

Платформы обычно предлагают несколько способов завершить PR.

Merge commit сохраняет ветку как отдельную линию истории:

main:    A -- B ----- M
              \     /
feature:       C -- D

Плюс: видно, что изменения пришли через PR. Минус: история может быть шумной.

Squash merge превращает все коммиты PR в один коммит в main:

git merge --squash feature/login
git commit -m "Add login feature"

Плюс: чистая история main. Минус: теряется детальная структура коммитов ветки.

Rebase and merge переносит коммиты PR поверх актуального main без merge commit:

main: A -- B -- C -- D

Плюс: линейная история. Минус: нужно понимать переписывание истории и аккуратно работать с конфликтами.

Нет универсально лучшей стратегии. Для учебного старта запомни практическое правило: маленькие PR хорошо squash-ить, большие изменения с осмысленными коммитами можно merge-ить отдельным merge commit.

CI в Pull Request

CI/CD обычно запускается на каждый push в PR. Проверки могут включать:

unit tests;
lint;
build Docker image;
security scan;
Terraform plan;
проверку YAML/Kubernetes manifests;
e2e или smoke tests.

Если CI красный, merge обычно запрещён. Это защищает main от очевидно сломанного состояния.

Но зелёный CI не заменяет review. Тесты показывают, что проверенные сценарии проходят. Ревьюер смотрит смысл изменения, риски и непроверенные случаи.

Размер PR

Маленький PR проще проверить и быстрее смержить.

Хороший PR обычно:

решает одну задачу;
имеет понятное описание;
не содержит случайных форматирований;
не смешивает refactor, feature и config change без необходимости;
имеет проверку.

Если в PR одновременно новый Helm chart, переименование директорий, форматирование всего репозитория и исправление production-багa, ревью становится почти бесполезным: слишком сложно понять, какая строка за что отвечает.

После merge

После merge локальную среду нужно синхронизировать:

git switch main
git pull origin main
git branch -d feature/add-login
git fetch --prune

git fetch --prune удаляет локальные remote-tracking ссылки на ветки, которые уже удалены на remote. Это помогает не держать в git branch -a старые PR-ветки.

Если после merge нужно откатить изменение, в командной истории чаще используют revert merge-коммита или revert squash-коммита, а не переписывание main.

Главная мысль

Git-команды дают техническую возможность менять историю. PR и code review дают командную дисциплину вокруг этой возможности.

Для DevOps это критично: изменения в репозитории часто автоматически запускают сборку, деплой или изменение инфраструктуры. Поэтому хороший Git-процесс - это не украшение, а часть production-безопасности.