Pull request / Merge request

Материал из llmdocs — справочник разработчика

Pull request / Merge request
Названия	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 в другую, оформленное на платформе разработки как отдельная страница: описание, список коммитов, построчный дифф, обсуждение, ревью и результаты автоматических проверок.^[1] Название зависит от платформы: GitHub и Bitbucket говорят «pull request», GitLab — «merge request»; суть одна.^[2] PR — основная единица командной работы с кодом: через него проходит почти каждое изменение основной ветки.

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

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

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

Разработчик создаёт ветку от основной (или форк чужого репозитория), делает коммиты и отправляет ветку на сервер.
Открывает PR: указывает целевую ветку, пишет описание — что и зачем изменено, как проверить, ссылки на задачу (Closes #123 закроет задачу при слиянии).
Запускаются автоматические проверки CI/CD: сборка, тесты, линтеры, сканеры безопасности.
Ревьюеры читают дифф, оставляют комментарии к строкам, предлагают правки (suggestions), одобряют или запрашивают изменения.
Автор отвечает и дописывает коммиты; PR обновляется автоматически.
Когда выполнены условия защиты ветки — нужные одобрения, зелёные проверки, нет конфликтов, — PR сливается и ветку удаляют.

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

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.

Код-ревью

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

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

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

# .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, которые ревьюят по очереди.
Ревью после слияния — в небольших доверенных командах изменения вливают сразу, а смотрят позже; скорость в обмен на риск.

См. также

Источники

Категории: