Pull Requests: полное руководство 🔀

Pull Request (PR) — это официальная просьба влить изменения из одной ветки в другую. Главный инструмент командной разработки.

Что такое Pull Request простыми словами

Представьте: вы работаете над новой функцией в отдельной ветке. Закончили. Теперь хотите чтобы изменения попали в основную ветку (main). Просто так взять и смёрджить — нехорошо, никто не проверил вашу работу.

Pull Request — это:
1. Показать команде что вы сделали
2. Попросить проверить перед мёрджем
3. Получить обратную связь и обсудить решения
4. Зафиксировать историю принятых решений

Ваша ветка:  feature/login ──●──●──●──●
                                        ↓ Pull Request
Основная:    main ──────────────────────●  ← merge

PR vs прямой коммит в main

В большинстве профессиональных команд прямые коммиты в main запрещены.

Как создать Pull Request

Шаг 1: Запушьте ветку

git push origin feature/my-feature

В GitHub Desktop: кнопка Push origin (или Publish branch при первом push).

Шаг 2: Откройте GitHub

После push GitHub покажет жёлтый баннер:

«feature/my-feature had recent pushes — Compare & pull request»

Нажмите на него или идите в Pull requests → New pull request.

Шаг 3: Выберите ветки

Убедитесь что направление правильное:

base: main  ←  compare: feature/my-feature
  ↑ куда                    ↑ откуда

Шаг 4: Заполните PR

• Заголовок — кратко и конкретно
• Описание — подробно (см. шаблон ниже)

Шаг 5: Создайте PR

Нажмите Create pull request.

Как писать хорошее описание PR

Плохое описание ❌

fix bug

update

Хорошее описание ✅

## Что сделано
Добавлена проверка поля `description` при создании задачи.
Теперь вместо 500 ошибки API возвращает корректный ответ.

## Зачем
Баг из тикета #47: задача без description вызывала краш сервиса.

## Как проверить
1. Открыть POST /api/tasks
2. Отправить запрос без поля description
3. Убедиться что ответ 200 с description: "Нет описания"

## Заметки
Временно использую дефолтное значение. Позже можно сделать
description nullable на уровне базы данных.

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

## Что сделано
[1-3 предложения о сути изменений]

## Зачем
[Контекст: проблема или задача]

## Как проверить
1. [Конкретный шаг]
2. [Конкретный шаг]

## Скриншоты / Демо
[Если есть визуальные изменения]

Анатомия страницы PR

Вкладка Conversation

Основная лента обсуждения. Комментарии ревьюеров, история событий (push, review, assign).

Вкладка Commits

Все коммиты которые войдут в merge. Каждый коммит — ссылка на diff.

Вкладка Files Changed ⭐

Главное место для ревью! Построчный diff всех изменённых файлов.
Можно добавлять inline комментарии к конкретным строкам.

Как обновить PR

После создания PR не нужно создавать новый если нужно что-то изменить.

Просто сделайте новый коммит в ту же ветку и запушьте — PR обновится автоматически:

PR #12: feat: добавить форму входа

Commits:
● feat: создана форма логина          ← первый push
● fix: исправлена валидация по замечанию ревью  ← после ревью
● docs: добавлены комментарии по просьбе     ← ещё правки

Статусы PR

Три стратегии merge

Merge commit (по умолчанию)

main: ──●──────────────────────●── 
                                ↑
feature:    ──●──●──●──────────/ (merge commit)

История полная, видны все коммиты feature-ветки. Рекомендуется для учёбы.

Squash and merge

main: ──●──────────────────────●── 
                                ↑
                          Один коммит со всем

Все коммиты feature-ветки «сжимаются» в один. Чистая история, но теряется детализация.

Rebase and merge

main: ──●──●──●──●──────────── 
              ↑↑↑
        Коммиты из feature «пересажены» на main

Линейная история без merge commit. Опыт для продвинутых.

После merge: удалите ветку

GitHub сразу предложит Delete branch. Соглашайтесь — ветка выполнила задачу.

Чтобы удалить локально:

git branch -d feature/my-feature

В GitHub Desktop переключитесь на main, потом Branch → Delete.

PR для разных сценариев

Обычный PR в команде

Вы member репозитория → push ветки → PR → ревью → merge.

PR из форка (Open Source)

Вы не member → fork → clone fork → push в форк → PR из форка в оригинал.

Подробнее в статье GitHub Fork: вносим вклад в чужой проект.

Полезные возможности PR

Draft PR — создайте PR заранее с пометкой «в процессе». Коллеги видят над чем работаете, могут дать ранний фидбек. Когда готово — нажмите «Ready for review».

Reviewers — назначьте конкретных людей для ревью. Они получат уведомление.

Assignees — кто ответственен за PR (обычно автор).

Labels — теги: bug, feature, documentation, help wanted.

Linked Issues — напишите в описании Closes #42 и PR автоматически закроет Issue при merge.

Почему PR важны для карьеры

Умение создавать хорошие PR — один из ключевых профессиональных навыков.

Работодатели смотрят на:
- Описания ваших PR в open source проектах
- Как вы реагируете на ревью
- Чистоту истории коммитов

Хороший PR показывает что вы думаете не только о коде, но и о команде.