Pull Request

Механизм предложения изменений в проект через GitHub: создание, описание, review и merge

Зачем нужно

  • Предложить изменения для code review перед merge
  • Обсудить реализацию с командой
  • Автоматически запустить CI/CD проверки
  • Документировать зачем и что было сделано

Где используется

  • Любая командная разработка
  • Open-source: вклад в чужие проекты
  • Даже одиночные разработчики используют PR для самоконтроля

Предпосылки

Создание Pull Request

Шаг 1: Подготовить ветку

# Обновить main
git switch main
git pull origin main

# Создать feature-ветку
git switch -c feature/user-auth

# Работать и коммитить
git add .
git commit -m "feat: добавить форму авторизации"
git add .
git commit -m "feat: подключить JWT-аутентификацию"

# Отправить ветку
git push -u origin feature/user-auth

Шаг 2: Создать PR на GitHub

  1. GitHub покажет баннер "Compare & pull request" — нажать
  2. Или: Pull requests → New pull request → выбрать ветки

Шаг 3: Заполнить описание

## Что сделано
- Добавлена форма авторизации (email + пароль)
- Реализована JWT-аутентификация на бэкенде
- Добавлена защита роутов

## Как проверить
1. Открыть /login
2. Ввести тестовые данные: test@mail.com / password123
3. Убедиться что перенаправляет на /dashboard

## Скриншоты
![форма логина](url-to-screenshot.png)

## Связанные задачи
Closes #42

Создание через CLI

gh pr create --title "feat: добавить авторизацию" --body "Описание PR"

# С интерактивным вводом
gh pr create

# Draft PR
gh pr create --draft

# С reviewer
gh pr create --reviewer teammate1,teammate2

Анатомия хорошего PR

Заголовок

feat: добавить авторизацию через Google OAuth
fix: исправить утечку памяти в WebSocket-подключении
refactor: вынести валидацию в отдельный модуль

Описание должно содержать

  • Что было сделано (кратко)
  • Зачем (контекст, ссылка на задачу)
  • Как проверить (шаги для reviewer)
  • Скриншоты (для UI-изменений)
  • Breaking changes (если есть)

Размер PR

  • Идеально: до 400 строк изменений
  • Допустимо: до 1000 строк
  • Плохо: 2000+ строк — разбивайте на несколько PR

Draft Pull Request

Черновик PR — работа ещё не закончена:

gh pr create --draft --title "WIP: новый дизайн профиля"
  • Нельзя merge
  • Reviewers видят что работа идёт
  • Когда готово → "Ready for review"

Стратегии Merge

1. Create a merge commit

main: A ── B ── M (merge commit)
              \  /
feature:       C ── D
  • Сохраняет все коммиты + merge-коммит
  • Видна полная история и ветвление

2. Squash and merge

main: A ── B ── CD (один коммит)
  • Все коммиты ветки объединяются в один
  • Чистая линейная история в main
  • Детали теряются (но сохраняются в PR)

3. Rebase and merge

main: A ── B ── C' ── D' (перебазированные коммиты)
  • Коммиты перебазируются на main
  • Линейная история, отдельные коммиты сохранены

Рекомендации по выбору

Ситуация Стратегия
Мелкий фикс, 1-3 коммита Squash and merge
Большая фича с логичными коммитами Rebase and merge
Нужна видимая история веток Merge commit
Команда хочет единообразие Выбрать одну и настроить в Settings

Обновление PR

# Добавить изменения по результатам review
git add .
git commit -m "fix: учесть замечания по code review"
git push
# PR обновится автоматически

# Обновить PR свежими изменениями из main
git switch feature/user-auth
git merge main
# или
git rebase main
git push --force-with-lease  # для rebase

Автоматическое закрытие Issues

В описании PR или коммите:

Closes #42
Fixes #42
Resolves #42

При merge PR — issue автоматически закроется.

Шаблон PR (PR Template)

Создайте файл .github/pull_request_template.md:

## Описание
<!-- Что и зачем было сделано -->

## Тип изменений
-  Новая функциональность (feat)
-  Исправление бага (fix)
-  Рефакторинг (refactor)
-  Документация (docs)

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

## Чек-лист
-  Тесты добавлены/обновлены
-  Документация обновлена
-  Нет console.log в коде

Частые ошибки

  • Огромные PR — более 1000 строк невозможно качественно отревьюить
  • Пустое описание — reviewer не понимает контекст
  • Merge без review — упускаются баги и проблемы
  • Не обновлять PR — ветка устаревает, merge-конфликты растут
  • Force push без --force-with-lease — можно перезаписать чужие коммиты

Практика

  1. Создайте ветку, сделайте изменения и создайте PR на GitHub
  2. Заполните описание по шаблону выше
  3. Создайте Draft PR и переведите в Ready
  4. Попробуйте все три стратегии merge
  5. Создайте PR через gh pr create
  6. Добавьте PR Template в свой репозиторий

Связанные темы

Ресурсы