# Pull Request (PR)

_Совместная работа · GitLab Knowledge Base_

**TL;DR:** Запрос на влитие ветки в основную с прохождением ревью и CI. На
GitHub/GitLab/Bitbucket - стандартный механизм совместной работы.
Технически это не команда Git, а функция хостинга, надстроенная
над веткой и серией коммитов.


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

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

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

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

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

   ```bash
   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](/courses/git/kb/merge-strategies.md)).

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

## Описание PR

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

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

## Что изменилось
- 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.


## Команды

```bash
gh pr create --title 'feat(auth): add login' --body 'Description'
```
Создать PR через GitHub CLI

```bash
gh pr checkout 123
```
Локально переключиться на ветку PR #123

```bash
gh pr review --approve
```
Approve PR из терминала

```bash
gh pr merge --squash --delete-branch
```
Смержить PR squash-стратегией и удалить ветку


## См. также

- [Code review](/courses/git/kb/code-review.md)
- [Стратегии merge PR (GitHub)](/courses/git/kb/merge-strategies.md)
- [git rebase](/courses/git/kb/rebase.md)