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

URL: https://skillaria.top/ru/guides/git/pull-request

Pull request (PR) — это запрос на слияние вашей ветки в основную ветку репозитория на GitHub: вы показываете изменения, коллеги их обсуждают и проверяют, после одобрения ветку сливают. В GitLab то же самое называется merge request (MR). Это функция платформы, а не команда Git, и с командой git pull она не связана.

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 | Pull request |
| --- | --- | --- |

| Где живёт | Команда Git в терминале | Страница на GitHub, GitLab, Bitbucket |

| Что делает | Забирает изменения с сервера к вам | Предлагает влить вашу ветку в чужую или общую |

| Кто участвует | Только вы | Автор, ревьюеры, CI |

| Нужна ли платформа | Нет, только remote | Да |

Отдельной команды «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 предлагает три способа, и администратор репозитория может оставить только часть из них.

| Способ | Что получится в main | Когда подходит |
| --- | --- | --- |

| Create a merge commit | Все коммиты ветки плюс merge-коммит | Нужна полная история и видно, какие коммиты пришли вместе |

| Squash and merge | Один коммит со всеми изменениями PR | В ветке много мелких «fix typo», важен чистый лог main |

| Rebase and merge | Коммиты ветки по одному, без merge-коммита | Коммиты аккуратные и каждый имеет смысл сам по себе |

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.

## FAQ

**Сколько ревьюеров нужно на pull request?**

Обычно хватает одного-двух. Минимальное число одобрений задаётся в правилах защиты ветки, и без них кнопка слияния будет недоступна.

**Можно ли создать pull request без форка?**

Да, если у вас есть права на запись в репозиторий: создайте ветку в нём самом и откройте PR из неё. Форк нужен, только когда прав на запись нет.

**Что делать, если PR долго не смотрят?**

Вежливо напомните ревьюеру в комментарии или в чате команды. В открытых проектах ожидание может занимать недели — проверьте, соответствует ли PR правилам CONTRIBUTING.md.

**Можно ли открыть pull request между двумя ветками своего форка?**

Да, на странице сравнения выберите свой форк и как base, и как head. Так удобно ревьюить собственные изменения перед отправкой в оригинальный проект.

**Почему в PR видны коммиты, которые я не делал?**

Скорее всего, ветка создана не от актуального main или выбрана не та base-ветка. Сделайте rebase на свежий main или поменяйте base в настройках PR.


---
Source: Skillaria.Top (https://skillaria.top)