# Pull request / Merge request

> Запрос на слияние изменений из одной ветки в другую с обсуждением, код-ревью и автоматическими проверками; на GitHub называется pull request, в GitLab — merge request.

Источник: https://llmdocs.ru/wiki/pull-request/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Названия**: pull request (GitHub, Bitbucket), merge request (GitLab)
- **Появление**: GitHub, 2008
- **Основа в Git**: команда git request-pull (2005)
- **Участники**: автор, ревьюеры, владельцы кода (CODEOWNERS)
- **Способы слияния**: merge commit, squash, rebase
- **Проверки**: CI, обязательные ревью, отсутствие конфликтов
**Pull request** (PR, «запрос на вытягивание») или **merge request** (MR, «запрос на слияние») — предложение влить изменения из одной ветки [Git](https://llmdocs.ru/wiki/git.md) в другую, оформленное на платформе разработки как отдельная страница: описание, список коммитов, построчный дифф, обсуждение, ревью и результаты автоматических проверок.[1] Название зависит от платформы: [GitHub](https://llmdocs.ru/wiki/github.md) и Bitbucket говорят «pull request», [GitLab](https://llmdocs.ru/wiki/gitlab.md) — «merge request»; суть одна.[2] PR — основная единица командной работы с кодом: через него проходит почти каждое изменение основной ветки.

## Откуда название

В самом Git есть команда `git request-pull` (2005): она формирует текстовое письмо с просьбой «вытянуть» (`git pull`) изменения из указанного репозитория — так до сих пор принимаются изменения в ядро Linux.[6] GitHub в 2008 году превратил это письмо в веб-страницу с обсуждением, а вместе с форками — в стандартный путь участия в открытых проектах. GitLab выбрал название, отражающее итоговое действие, — слияние.

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

1. Разработчик создаёт ветку от основной (или форк чужого репозитория), делает коммиты и отправляет ветку на сервер.
2. Открывает PR: указывает целевую ветку, пишет описание — что и зачем изменено, как проверить, ссылки на задачу (`Closes #123` закроет задачу при слиянии).
3. Запускаются автоматические проверки [CI/CD](https://llmdocs.ru/wiki/ci-cd.md): сборка, тесты, линтеры, сканеры безопасности.
4. Ревьюеры читают дифф, оставляют комментарии к строкам, предлагают правки (*suggestions*), одобряют или запрашивают изменения.
5. Автор отвечает и дописывает коммиты; PR обновляется автоматически.
6. Когда выполнены условия защиты ветки — нужные одобрения, зелёные проверки, нет конфликтов, — PR сливается и ветку удаляют.

**Черновик** (*draft*) PR открывают заранее, чтобы показать ход работы и прогнать CI, — слить его нельзя, пока автор не отметит готовность.

```bash
git switch -c fix/login-timeout
git commit -am "Увеличить таймаут входа до 30 секунд"
git push -u origin fix/login-timeout
gh pr create --fill --draft          # GitHub CLI
glab mr create --fill                # GitLab CLI
```

## Способы слияния

Платформы предлагают три кнопки (доступные варианты настраиваются в репозитории):[3]

| Способ | Результат в основной ветке |
|---|---|
| Merge commit | все коммиты ветки + коммит слияния; история полная |
| Squash and merge | один коммит на весь PR; история основной ветки чистая |
| Rebase and merge | коммиты ветки переносятся поверх, без коммита слияния; история линейная |

Подробно о различиях — в статье [Merge и rebase](https://llmdocs.ru/wiki/merge-rebase.md).

## Код-ревью

Ревью — главная ценность PR: второй человек находит ошибки, следит за архитектурой и распространяет знание о коде в команде. Рекомендации из практики крупных компаний:[5]

- **маленькие PR** — изменения на 100–300 строк ревьюят быстрее и внимательнее, чем на 2000;
- **один PR — одна задача**, рефакторинг отдельно от новой функциональности;
- описание отвечает на вопрос «зачем», а не пересказывает дифф;
- комментарии — о коде, а не об авторе; мелочи помечают как необязательные (`nit:`);
- стиль и форматирование проверяют автоматически (линтеры, форматтеры), а не люди.

Файл **CODEOWNERS** назначает ответственных за каталоги и файлы: при изменении `infra/` в ревьюеры автоматически добавляется команда инфраструктуры, а правила защиты ветки могут требовать её одобрения.[4]

```text
# .github/CODEOWNERS
*.py          @example/backend
/infra/       @example/platform
/docs/        @example/tech-writers
```

## Шаблоны и автоматизация

Шаблон описания (`.github/pull_request_template.md`, в GitLab — `.gitlab/merge_request_templates/`) задаёт чек-лист: тесты, миграции, документация. Боты обновляют зависимости собственными PR (Dependabot, Renovate), а ИИ-ассистенты всё чаще выполняют первичное ревью и описывают изменения. Очередь слияния (*merge queue*) последовательно проверяет PR поверх свежей основной ветки, чтобы два по отдельности зелёных изменения не сломали её вместе.

## Подходы

- **Короткоживущие ветки** (GitHub Flow, trunk-based) — PR живёт часы или дни; чем дольше ветка, тем болезненнее конфликты.
- **Стековые PR** (*stacked PRs*) — большая задача разбивается на цепочку зависимых PR, которые ревьюят по очереди.
- **Ревью после слияния** — в небольших доверенных командах изменения вливают сразу, а смотрят позже; скорость в обмен на риск.

## См. также

- [Ветвление в Git](https://llmdocs.ru/wiki/git-branching.md)
- [Merge и rebase](https://llmdocs.ru/wiki/merge-rebase.md)
- [GitHub Actions](https://llmdocs.ru/wiki/github-actions.md)
- [GitLab CI](https://llmdocs.ru/wiki/gitlab-ci.md)

## Источники

1. [GitHub Docs — About pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
2. [GitLab Docs — Merge requests](https://docs.gitlab.com/user/project/merge_requests/)
3. [GitHub Docs — About merge methods on GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github)
4. [GitHub Docs — About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)
5. [Google Engineering Practices — Code Review Developer Guide](https://google.github.io/eng-practices/review/)
6. [git-request-pull documentation](https://git-scm.com/docs/git-request-pull)