# Draft pull request

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

**TL;DR:** Состояние PR, сигнализирующее «работа не закончена, не ревьювите
сейчас». CI на draft PR работает, но reviewer'ы не назначаются
автоматически, и merge кнопка заблокирована. Promote в обычный PR
через `gh pr ready` или кнопку «Ready for review».


Draft PR - это обычный pull request в специальном состоянии. Он
существует на сервере, его виден всем, на нём запускается CI - но
GitHub знает, что автор ещё работает, и:

- **Не назначает reviewer'ов автоматически** (по CODEOWNERS).
- **Не отправляет notification «requested your review».**
- **Блокирует merge** до перевода в ready.

Это формализация старой практики «PR с префиксом WIP в заголовке».
Draft умеет то же самое, но GitHub помогает соблюдать правила.

## Зачем draft

- **Получить feedback на ранний прототип.** Открываешь draft,
  кидаешь ссылку в чат: «вот черновик, посмотрите подход, не
  смотрите детали». Reviewer'ы понимают, что это не final.
- **Прогнать CI до того, как считаешь PR готовым.** Иногда нужно
  увидеть «зелёное» или «красное» от тестов, прежде чем дать на
  review коллегам. Draft позволяет это без шума.
- **Зафиксировать работу публично.** Команда видит, что ты что-то
  делаешь, может зайти и обсудить, но никто не зовётся ревьюить
  прямо сейчас.
- **Stacked PRs.** Зависимые PR'ы часто открывают как draft, и
  переводят в ready по очереди, когда базовый PR смержен.

## Создание

```bash
# через gh
gh pr create --draft

# или через UI: при создании PR нажать на dropdown рядом с
# кнопкой «Create pull request» и выбрать «Create draft pull request»
```

## Перевод в ready

```bash
gh pr ready              # текущий PR (на текущей ветке)
gh pr ready 123          # конкретный по номеру
```

Или в UI кнопка «Ready for review». После этого:

- CODEOWNERS назначает reviewer'ов.
- Reviewer'ы получают notification.
- Merge становится возможным (при выполнении остальных условий).

Обратное преобразование тоже есть:

```bash
gh pr ready --undo
```

Полезно, если перевёл в ready преждевременно.

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

- **Draft не значит «приватный».** PR виден всем, кто видит репо.
  Если хочется приватной работы - используй приватную ветку или
  приватный fork.
- **CI всё равно работает.** Если у вас платный CI и обычная
  fight за раннеры, draft не экономит ресурсы. Иногда команды
  настраивают workflow с условием «не запускать на draft».
- **CODEOWNERS не назначается, но можно вручную.** Если хочешь
  конкретного reviewer'а даже на draft - добавь через
  `gh pr edit --add-reviewer @alice`.
- **На некоторых тарифах GitHub draft PR недоступен** (старые
  бесплатные private репо). На большинстве современных доступен.

## Альтернатива: коммиты в feature-ветке без PR

Если работа очень ранняя, иногда проще просто коммитить в
feature-ветку без открытия PR. Когда захочется feedback - тогда и
откроешь draft. Open draft PR полезен, когда хочется CI и
публичная видимость; до этого момента иногда удобнее не
показывать недописанный код.


## Команды

```bash
gh pr create --draft -t 'WIP: refactor auth'
```
Создать draft PR с заголовком

```bash
gh pr ready
```
Перевести текущий PR из draft в ready for review

```bash
gh pr ready --undo
```
Вернуть PR в draft (если рано перевёл в ready)


## См. также

- [Pull Request (PR)](/courses/git/kb/pull-request.md)
- [Code review](/courses/git/kb/code-review.md)
- [Pull Request template](/courses/git/kb/pr-template.md)