Що таке Pull Request: навіщо команди переглядають код перед злиттям

Що таке Pull Request і чому це не формальність

Pull Request (PR) — це коли ти кажеш команді: «я зробив зміни, подивіться, все гаразд, перш ніж я додам їх до основного коду». Звучить просто. Але хороший PR — це набагато більше ніж кнопка “Merge”.

Навіщо це взагалі

1. Знаходження помилок раніше, ніж до користувачів

Другий погляд на код часто знаходить те, що автор пропустив: логічну помилку, проблему безпеки, поганий підхід до обробки помилок.

2. Обмін знаннями

Через review кожен бачить код інших і вчиться. Новачки розуміють, як роблять старші розробники, старші бачать незвичайні підходи.

3. Документація змін

PR з хорошим описом — це запис: що змінилося, чому, які були альтернативи. Через півроку хтось (можливо ти сам) відкриє історію і зрозуміє, чому саме так зроблено.

4. Запобігання «одному герою»

Якщо тільки одна людина знає, як працює критична частина системи — це ризик. Code review розподіляє знання.

Як виглядає хороший PR

Заголовок

Коротко і зрозуміло. Не “fix stuff”, а “Fix login redirect after password reset”.

Опис

Що змінилося (1-2 речення)
Чому (проблема/запит користувача/баг)
Як перевірити (кроки, скріншоти, відео)
Пов’язані задачі (посилання на issue/тикет)

## Що
Додано перевірку дублікатів email при реєстрації.

## Чому
Користувачі могли реєструватися з одним email кілька разів.

## Як перевірити
1. Відкрий /register
2. Зареєструйся з існуючим email
3. Має з'явитися помилка "Email already registered"

Fixes #42

Як робити маленькі PR замість одного великого

Погано: 47 файлів, 1200 рядків, “added user system and fixed bugs and refactored login”

Добре:

PR #1: “Add email validation utility” (3 файли, 45 рядків)
PR #2: “Add duplicate email check to registration” (2 файли, 30 рядків)
PR #3: “Update registration form error messages” (1 файл, 15 рядків)

Маленькі PR:

легше ревьювати (5-15 хвилин замість години);
швидше мерджаться;
якщо щось зламається — легше знайти причину;
reviewer менше стресує.

Типові помилки

1. “Тут все просто, ревью не потрібно”

Прості зміни теж можуть мати побічні ефекти. Крім того, PR — це не тільки перевірка якості, а й документування. Хтось інший має знати, що було змінено.

2. Один величезний PR на все

Коли PR містить 20 фіч, 15 баг-фіксів і рефакторинг логіки — reviewer або швидко кліпає “approve” не читаючи (що безглуздо), або витрачає годину (що теж погано).

3. Ігнорувати коментарі reviewer-а

Якщо тобі сказали змінити щось — або зміни, або аргументовано поясни, чому залишаєш як є. Мовчання = “я проігнорував” = проблеми з довірою в команді.

4. Мерджати без перевірки результатів CI

Якщо тести не пройшли — це не “дрібниці, пізніше полагоджу”. Це сигнал, що щось зламано.

5. Не оновлювати гілку з main

Коли хтось інший змінив main, а твоя гілка стара — merge conflict при злитті неминучий. Робочий звичай: git pull origin main перед створенням PR.

Висновок / план дії

Pull Request — це не бюрократія. Це інструмент, який робить код кращим, а команду — сильнішою.

Що зробити найближчим часом:

Наступного разу створи PR, навіть якщо зміни маленькі — це звичка.
Напиши опис: що, чому, як перевірити.
Зроби PR маленьким — 1-3 файли, логічно завершена зміна.
Перевір, що CI зелені, перед тим як просити review.
Відповідай на коментарі — швидко і з повагою.

Хороший PR — це знак професіоналізму. Це каже: «я зробив свою роботу і хочу, щоб команда її перевірила, перш ніж вона стане частиною нашого продукту».