git remotes GitHub

Pull Request

Запрос на включение изменений — основной инструмент code review и совместной разработки

Описание

Pull Request (PR) — это запрос от разработчика к владельцу репозитория принять его изменения (merge ветку). PR — не команда Git, а функция платформы (GitHub, GitLab, Bitbucket). На GitLab этот механизм называется Merge Request (MR), но суть та же.

PR решает сразу несколько задач: предоставляет единое место для обсуждения изменений, запускает автоматические проверки (CI/CD, линтеры, тесты), организует code review (рецензирование кода), документирует историю принятых решений. Даже в командах из одного человека PR-workflow полезен: он добавляет паузу перед слиянием, позволяя перечитать изменения «свежим взглядом».

Хороший PR: маленький и сфокусированный (одна задача), с понятным описанием (что изменилось и зачем), с тестами, покрывающими изменения, без конфликтов с target-веткой. Мейнтейнеры больших проектов читают десятки PR в неделю — качественное описание и чистая история коммитов значительно ускоряют рассмотрение.

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

🌿

Создание ветки и работа

Разработчик создаёт feature-ветку от актуального main, вносит изменения, коммитит.

🚀

Push ветки на remote

git push -u origin feature/my-feature — GitHub покажет кнопку «Compare & pull request».

📝

Открытие PR

Заполнить название, описание, назначить reviewers, labels, milestone. Привязать к issue через «Fixes #123».

🤖

Автоматические проверки (CI)

GitHub Actions / другой CI запускает тесты, линтеры, проверку типов. Статус отображается прямо в PR.

👀

Code Review

Reviewers оставляют комментарии, запрашивают изменения (Request changes) или одобряют (Approve). Автор вносит правки и пушит новые коммиты — PR обновляется автоматически.

✅

Merge

После одобрения и прохождения CI мейнтейнер сливает PR. Ветку можно удалить сразу после merge (GitHub предложит).

Стратегии слияния PR

GitHub предлагает три способа слить PR. Выбор зависит от политики команды.

Merge commit

Создаёт merge-коммит. Сохраняет полную историю всех коммитов ветки. История становится нелинейной.

Squash and merge

Сжимает все коммиты ветки в один перед слиянием. Чистый main с одним коммитом на задачу. Оригинальная история теряется.

Rebase and merge

Переписывает коммиты ветки поверх main. Линейная история без merge-коммита. Меняет хеши коммитов.

Концепция	Пояснение
`base branch`	Ветка-цель, в которую будут влиты изменения. Обычно `main` или `develop`.
`compare branch`	Ваша feature-ветка с изменениями.
`Draft PR`	Черновой PR — запускает CI, но сигнализирует, что работа не закончена. Reviewers не получают уведомления. Конвертируется в обычный PR нажатием кнопки.
`Fixes #<issue>`	Магическая фраза в описании PR. После merge автоматически закроет связанный issue. Работают также: Closes, Resolves.
`CODEOWNERS`	Файл в репозитории, задающий автоматических reviewers для разных частей кодовой базы. Если изменён файл из зоны ответственности — reviewer назначается автоматически.
`Protected branch`	Ветка с ограничениями: нельзя пушить напрямую, нужно минимальное количество approvals, CI должен пройти. Настраивается в Settings → Branches на GitHub.
`Review: Approve`	Reviewer одобрил изменения. PR можно сливать (если число approvals достигнуто).
`Review: Request changes`	Reviewer требует доработки. PR нельзя слить, пока автор не внесёт изменения и reviewer не одобрит снова.
`gh pr create`	Создать PR из командной строки через GitHub CLI. Удобно в автоматизации. Пример: `gh pr create --title "feat: dark mode" --body "..."`
`gh pr checkout`	Переключиться на ветку чужого PR локально: `gh pr checkout 42`. Удобно для review и тестирования.

Паттерны использования

Создать PR через GitHub CLI

# Установить GitHub CLI: https://cli.github.com
# Авторизоваться
gh auth login

# Создать PR из текущей ветки
gh pr create \
  --title "feat: add dark mode" \
  --body "## Changes\n- Added toggle\n\nFixes #42" \
  --label "enhancement"

Посмотреть и проверить чужой PR

# Список открытых PR
gh pr list

# Переключиться на ветку PR #42
gh pr checkout 42

# Запустить тесты локально
npm test

# Оставить комментарий
gh pr review 42 --comment -b "LGTM, but check edge case"

Обновить PR после review

# Внести правки после Request changes
git add fixed-file.py
git commit -m "fix: handle edge case in dark mode"

# Push — PR обновится автоматически
git push origin feature/dark-mode

# Попросить повторный review
gh pr review 42 --request-review @reviewer

Draft PR для ранней обратной связи

# Создать черновой PR
gh pr create --draft \
  --title "WIP: refactor auth module" \
  --body "Early feedback welcome on the API design"

# Конвертировать в обычный PR
gh pr ready

Шаблон описания PR

# Создать файл .github/PULL_REQUEST_TEMPLATE.md:
## Что изменилось
-

## Зачем
Closes #

## Как проверить
1.
2.

## Чеклист
- [ ] Тесты написаны/обновлены
- [ ] Документация обновлена

Слить и удалить ветку локально

# После merge PR на GitHub
git checkout main
git pull origin main

# Удалить локальную ветку
git branch -d feature/dark-mode

# Удалить remote-ветку (если не удалил GitHub)
git push origin --delete feature/dark-mode

# Или одной командой через gh
gh pr merge 42 --squash --delete-branch

Советы и подводные камни

Пишите описание PR для reviewer, не для себя: Хорошее описание отвечает на три вопроса: что изменилось, зачем это нужно, как проверить. Добавьте скриншоты для UI-изменений. PR с понятным описанием рассматривают в разы быстрее — это уважение к времени reviewer.

Маленькие PR быстро сливают: PR с 50 изменёнными строками проверяется за 10 минут, PR с 500 строками — может неделями ждать в очереди. Разбивайте большие задачи на последовательные маленькие PR. Используйте Draft PR, чтобы получить ранний фидбэк по архитектуре.

Конфликты при слиянии: Если PR долго ждёт review, а тем временем в main пришли изменения, возникают конфликты. Разрешить их можно двумя способами: git rebase main (чистая история, но меняет хеши коммитов) или git merge main (сохраняет хеши, но добавляет merge-коммит). После разрешения конфликтов — git push --force-with-lease.

Не пушьте credentials и .env в PR: Перед открытием PR проверьте, что в diff нет секретов, паролей, токенов. Даже если вы удалите их в следующем коммите, в истории PR они останутся. Используйте .gitignore с первого дня проекта и инструменты вроде git-secrets или gitleaks.