Pull Request (PR)

Pull Request (или Merge Request в GitLab/Bitbucket) - это не часть Git, а удобная обёртка хостинга. Git знает только ветки и коммиты; «запрос на влитие» - это:

• указание двух веток (source и target);
• набор коммитов между ними;
• страница для обсуждения и ревью;
• привязка к CI-проверкам;
• кнопка для финального merge.

На разных платформах называется по-разному (GitHub: PR, GitLab: MR, Bitbucket: PR), но устройство одинаковое.

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

1. Создать ветку, сделать коммиты, запушить:

   bashcopy

   git switch -c feat/login

   # ... коммиты ...

   git push -u origin feat/login

2. Открыть PR через UI (или через gh pr create / glab mr create). Указать target (обычно main), описание изменений, список ревьюеров.

3. CI прогонит проверки - тесты, линтер, билд, security-scan. Зелёный CI - пред-условие для merge в большинстве проектов.

4. Ревью. Коллеги комментируют код, оставляют suggestions, запрашивают изменения или approve.

5. Цикл правок. Делаешь новые коммиты или amend в той же ветке, git push - PR обновляется автоматически.

6. Merge. После approve и зелёного CI - кнопка merge. Стратегия (merge commit / squash / rebase-merge) выбирается тут (см. merge-strategies).

7. Удаление ветки. После merge ветка обычно удаляется (на GitHub есть автонастройка).

Описание PR

Полезная структура (есть шаблоны в репо через .github/PULL_REQUEST_TEMPLATE.md):

## Зачем

В двух предложениях - мотивация. Ссылка на тикет.

## Что изменилось

- feat: добавлена форма password reset

- refactor: вынес валидатор в отдельный модуль

- test: покрытие 87% → 92%

## Как проверить

1. Запустить локально

2. Открыть /reset-password

3. Ввести email, проверить письмо

## Скриншоты

(если UI)

## Чек-лист

- [x] Тесты добавлены

- [x] Документация обновлена

- [ ] Migration требуется → запустить в staging

Хороший PR-description экономит часы ревьюеру и будущему разработчику, который наткнётся на изменение через год.

Размер PR

Главный фактор скорости и качества ревью - размер. Точных «процентов отловленных багов» никто честно не измерял, но направление одинаковое у всех команд:

• Маленький (десятки-сотни строк) - читается за один присест, ревьюер видит каждую строку.
• Средний (несколько сотен) - всё ещё реально, но требует блок времени и концентрации.
• Большой (>500-1000 строк) - ревьюер устаёт, скользит по диагонали, легко пропускает баги. Часто approve'ят, чтобы не блокировать.

Если PR разрастается - разбивай. Лучше серия из 4 небольших PR'ов, чем один на 800 строк.

Stacked PRs

Когда фича большая и разбить на независимые PR'ы не выходит - серия зависимых PR'ов, по очереди мержащихся:

PR #1: feat/login-form-skeleton    (target: main)

PR #2: feat/login-form-validation  (target: feat/login-form-skeleton)

PR #3: feat/login-form-styling     (target: feat/login-form-validation)

Каждый PR ревьюится отдельно, мержится в порядке зависимости. Инструменты типа Graphite / git-stack автоматизируют пересборку стека после merge базового PR.

Подводные камни

• Не пушь force-with-lease на ветку PR, если кто-то её уже проверяет - комментарии к строкам отвалятся (новые SHA → нет привязки). Допустимо до начала ревью; после - лучше дополнительные коммиты + squash при merge.
  • Конфликт с main возникает, когда main ушёл вперёд. Решение - rebase своей ветки на main (git rebase main) или merge main в свою (git merge main). Rebase даёт более чистую историю, merge проще.
  • Auto-merge - настройка в GitHub: PR смержится автоматически, как только все условия (approve + CI) выполнены. Удобно, но помни про неё - иногда хочешь подержать PR.