Pull request в Git: что это и как создать PR на GitHub

Pull request (PR) — это предложение влить изменения из одной ветки в другую, оформленное на платформе вроде GitHub. Вы отправляете ветку на сервер, открываете PR, и команда видит дифф, комментирует строки, запускает автоматические проверки и только потом нажимает кнопку слияния. В GitLab тот же механизм называется merge request (MR). Если коротко отвечать на вопрос «git pull request что это» — это точка контроля между «я написал код» и «код попал в main».

Git pull request что это и откуда название

Название сложилось исторически. Автор изменений просит владельца репозитория «подтянуть» (pull) его ветку к себе — отсюда pull request. В GitLab решили назвать вещь по результату — merge request, запрос на слияние. Bitbucket и Azure DevOps используют вариант «pull request». По сути это одно и то же: ветка-источник, ветка-цель, описание, обсуждение, проверки и кнопка слияния.

Важно понимать: pull request — это не часть Git. В самом Git нет объекта «PR», его нельзя создать коммитом или найти в папке .git. Это сущность платформы: GitHub хранит описание, комментарии и статусы проверок у себя, а Git отвечает только за ветки и коммиты, которые в PR входят.

Сокращение PR в разговоре разработчиков почти всегда означает pull request: «кинь PR», «PR на ревью», «смёржил PR». Для GitLab говорят MR.

Pull request и git pull: в чём разница

Из-за похожих слов эти вещи постоянно путают. Команда git pull скачивает новые коммиты с удалённого репозитория и сразу вливает их в вашу текущую ветку — это локальная операция в терминале. Pull request — веб-страница на GitHub с предложением слить одну ветку в другую.

Отдельной команды «git pull request» в Git нет. Есть старая утилита git request-pull, но она лишь генерирует текст письма со сводкой изменений для рассылки и к PR на GitHub отношения не имеет.

Зачем нужны pull request'ы

Пока проект ведёт один человек, можно коммитить прямо в main. Как только в репозитории двое и больше, прямые push в основную ветку становятся источником сломанных сборок и потерянной работы. Pull request решает сразу несколько задач:

• ревью кода — второй человек видит изменения до того, как они попадут в main, и ловит ошибки, которые автор пропустил;
• автоматические проверки — GitHub Actions или другой CI запускает тесты и линтеры на каждый PR, и красный статус не даст слить сломанный код;
• история решений — через год по PR можно понять не только что поменяли, но и почему, с обсуждением;
• вклад в чужие проекты — в open source у вас нет прав на запись, и PR из форка — единственный способ предложить исправление;
• защита веток — правила защиты ветки на GitHub могут запретить прямой push в main и требовать одобренный PR.

Как создать pull request на GitHub из ветки

Это основной сценарий для команды, где у всех есть права на запись в репозиторий. Работа идёт в feature-ветке, а main меняется только через PR.

Шаг 1. Создайте ветку от свежего main

git switch main
git pull
git switch -c feature/login-form

Имя ветки лучше делать говорящим: feature/…, fix/…, номер задачи. Ревьюеру сразу понятно, о чём пойдёт речь.

Шаг 2. Сделайте коммиты

git add src/login.js
git commit -m "Добавить форму входа"

Один PR — одна задача. Маленький PR на 100–300 строк проверяют быстро и внимательно, а на 3000 строк ревьюер ставит одобрение не глядя.

Шаг 3. Отправьте ветку на сервер (git push для pull request)

git push -u origin feature/login-form

Флаг -u связывает локальную ветку с удалённой, и дальше хватит простого git push. В ответе GitHub сам подскажет ссылку для создания PR:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form

Шаг 4. Откройте PR в веб-интерфейсе

Перейдите по ссылке из терминала или откройте репозиторий на GitHub — после свежего push там появляется плашка с кнопкой «Compare & pull request». Ещё один путь — вкладка «Pull requests» и кнопка «New pull request».

1. Проверьте пару веток: base — куда сливаем (обычно main), compare — ваша ветка.
2. Напишите заголовок: что сделано, в повелительном наклонении или кратким описанием.
3. В описании объясните зачем, как проверить и что осталось за рамками. Если в репозитории есть шаблон PR, поля подставятся сами.
4. Справа назначьте ревьюеров (Reviewers), исполнителя и метки, если команда их использует.
5. Нажмите «Create pull request» или выберите черновик (об этом ниже).

Создать PR из терминала: GitHub CLI

Если не хочется переключаться в браузер, есть официальная утилита gh. Это не команда Git, а отдельная программа GitHub, но для PR она удобна:

gh pr create --base main --title "Добавить форму входа" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

На вопрос «git команды pull request» честный ответ такой: Git умеет ветки, коммиты и push, а сам PR создаётся на платформе — в браузере, через gh или API.

Как сделать pull request в чужой репозиторий через форк

В открытых проектах прав на запись у вас нет. Поэтому сначала вы делаете форк — свою копию репозитория на GitHub, — работаете в ней и предлагаете изменения оригиналу.

1. На странице проекта нажмите «Fork» — у вас появится github.com/you/project.
2. Клонируйте свой форк и добавьте оригинал как второй remote, обычно его называют upstream.
3. Создайте ветку, сделайте коммиты и отправьте ветку в свой форк.
4. На GitHub откройте PR: base repository — оригинальный проект, head repository — ваш форк и ваша ветка.

git clone git@github.com:you/project.git
cd project
git remote add upstream https://github.com/owner/project.git
git switch -c fix/typo-readme
git commit -am "Исправить опечатку в README"
git push -u origin fix/typo-readme

Перед работой загляните в файл CONTRIBUTING.md: там обычно описаны правила оформления коммитов, тесты и то, нужно ли сначала создавать issue. Держите форк в актуальном состоянии: git fetch upstream и git rebase upstream/main в своей ветке, чтобы PR не отставал от оригинала.

Merge request в GitLab: что это и как создать

Merge request git-платформы GitLab — полный аналог pull request. Отличаются названия и детали интерфейса, а процесс тот же: ветка, push, запрос на слияние, ревью, слияние.

Создать MR можно несколькими способами:

• через ссылку, которую GitLab печатает в терминале после git push новой ветки;
• в разделе Merge requests проекта кнопкой «New merge request», выбрав исходную и целевую ветки;
• прямо при push, с помощью push options GitLab — без захода в браузер.

git push -o merge_request.create -o merge_request.target=main origin feature/login-form

Терминология GitLab немного другая: одобрение называется approve, ответственный за слияние — assignee, вместо GitHub Actions работает GitLab CI/CD с файлом .gitlab-ci.yml. Черновики MR тоже есть — они называются Draft.

Ревью pull request

Ревьюер открывает вкладку «Files changed» и видит дифф. На любую строку можно оставить комментарий или предложить готовую правку (suggestion), которую автор применит одной кнопкой. Комментарии собираются в ревью и отправляются разом с одним из вердиктов:

• Comment — просто замечания без решения;
• Approve — изменения одобрены;
• Request changes — нужно доработать, слияние нежелательно.

Хорошее ревью смотрит на логику, читаемость, тесты и крайние случаи, а не спорит о вкусах — форматирование лучше доверить линтеру в CI. Автору стоит отвечать на каждый комментарий: исправил, обсудили, оставляем как есть с объяснением.

Как проверить чужой PR локально (git checkout pull request)

Иногда код нужно запустить у себя. Если ветка лежит в том же репозитории, хватит git fetch и git switch. Для PR из форка GitHub отдаёт специальные ссылки pull/<номер>/head:

git fetch origin pull/57/head:pr-57
git switch pr-57

В GitLab аналогичные ссылки называются merge-requests/<номер>/head. Или просто gh pr checkout 57, если стоит GitHub CLI.

Как обновить pull request после замечаний

PR привязан к ветке, а не к конкретным коммитам. Достаточно сделать новые коммиты в ту же ветку и отправить их — PR обновится сам, новых запросов создавать не нужно.

git commit -am "Учесть замечания ревью"
git push

Git rebase pull request: подтянуть свежий main

Пока PR висит на ревью, main уходит вперёд. Если GitHub пишет, что ветка устарела или есть конфликты, обновите её. Вариант с rebase даёт линейную историю:

git fetch origin
git rebase origin/main
# разрешить конфликты, git add, git rebase --continue
git push --force-with-lease

После rebase хеши коммитов меняются, поэтому обычный push будет отклонён — нужен принудительный. Используйте --force-with-lease: он откажется перезаписывать ветку, если в ней появились чужие коммиты. Если в ветке работаете не только вы, безопаснее влить main через git merge origin/main — без переписывания истории.

Как слить pull request: merge, squash и rebase

Когда ревью одобрено и проверки зелёные, PR можно сливать. GitHub предлагает три способа, и администратор репозитория может оставить только часть из них.

Merge pull request через интерфейс — по сути тот же git merge, только выполненный на сервере. После слияния GitHub предложит удалить ветку — соглашайтесь, она больше не нужна. Локально почистите за собой:

git switch main
git pull
git branch -d feature/login-form

Слить PR можно и вручную из терминала: влить ветку в main локально и запушить. GitHub распознает, что коммиты ветки попали в base, и сам пометит PR как merged. Но так теряются проверки и правила защиты ветки, поэтому в командах обычно сливают кнопкой.

Auto-merge и merge queue

Если проверки идут долго, можно включить автоматическое слияние: PR сольётся сам, когда все условия будут выполнены. В больших репозиториях используют очередь слияния (merge queue), которая проверяет PR поверх уже стоящих в очереди, чтобы main не ломался от несовместимых изменений.

Черновики pull request (Draft)

Черновик — PR, который ещё не готов к ревью. Его нельзя слить, а ревьюеры не получают запрос на проверку. Черновики удобны, чтобы рано показать направление, запустить CI или собрать мнение по архитектуре. На GitHub при создании PR выберите вариант черновика в выпадающем меню кнопки создания или выполните gh pr create --draft. Когда работа готова, нажмите «Ready for review». В GitLab черновик помечается префиксом Draft: в заголовке MR.

Связь pull request с issues

Если в описании PR написать ключевое слово и номер задачи, после слияния в ветку по умолчанию GitHub закроет issue автоматически:

Closes #42
Fixes #17
Resolves #8

Работают слова close, fix, resolve в разных формах (closes, fixed, resolves). Просто упоминание #42 без ключевого слова создаст ссылку, но задачу не закроет. В GitLab аналогично работают Closes #42 и похожие фразы.

Можно ли удалить pull request или merge request

Удалить PR на GitHub обычный участник не может — его можно только закрыть кнопкой «Close pull request». Закрытый PR остаётся в истории, его можно открыть снова. Ветку после закрытия удаляйте отдельно. Полностью удалить PR можно только через поддержку GitHub, например если туда попали секреты.

В GitLab закрыть MR может автор или участник с правами, а удалить — владелец проекта или администратор. Если в PR попал пароль или токен, закрытия мало: сразу отзовите секрет, потому что коммиты уже были на сервере.

Типичные ошибки с pull request

• PR из main. Вы закоммитили в свой main и открыли PR из него. Следующий PR будет содержать и старые изменения. Работайте всегда в отдельной ветке.
• Неправильная base-ветка. PR открыт в develop вместо main или наоборот. Base можно поменять кнопкой Edit рядом с заголовком PR.
• В дифф попали лишние файлы. Сборки, node_modules, .env. Добавьте их в .gitignore и уберите из индекса через git rm --cached.
• Огромный PR. Разбейте задачу на несколько последовательных PR.
• Обычный push после rebase. Ошибка rejected (non-fast-forward). Нужен git push --force-with-lease, а не --force.
• Конфликты. Не разрешайте их в веб-редакторе вслепую — подтяните main локально, разрешите и проверьте тесты.

Pull request в git flow и других процессах

Pull request вписывается в любой командный процесс. В GitHub Flow всё просто: ветка от main, PR, ревью, слияние, деплой. В git flow PR открываются в develop из feature-веток, а релизные и hotfix-ветки тоже проходят через PR в main. В trunk-based разработке PR короткие и живут часы, а не дни. Какой бы процесс ни был, правило одно: изменения в общие ветки идут только через pull request.

Итог

Pull request — механизм платформы, а не команда Git: ветка, отправленная на сервер, плюс страница с обсуждением, ревью и проверками. В GitLab это merge request, в разговоре — PR и MR. Создавайте PR из отдельной ветки, держите его небольшим, обновляйте push в ту же ветку и выбирайте способ слияния под историю проекта. Форки, feature-ветки и pull request'ы разобраны на практике в курсе по Git.