Магія Pull Requests

1. Від злиття до запиту: навіщо потрібні Pull Requests?

На минулій лекції ми навчилися зливати (merge) гілки на своєму локальному компʼютері. Це чудово працює, коли ви працюєте поодинці. Але що, якщо над проєктом працює ціла команда? Якщо кожен буде зливати свої зміни безпосередньо в основну гілку main, дуже скоро почнеться хаос: хтось може випадково додати код із помилками, зламати збірку або видалити важливу частину роботи колеги.

Щоб цього уникнути, у командній розробці прийнято інший підхід. Замість того, щоб одразу зливати зміни, ви створюєте запит на злиття. Такий запит називається Pull Request (скорочено PR) або, на деяких платформах, Merge Request.

Pull Request — це офіційний запит: «Будь ласка, заберіть (pull) мої зміни з моєї гілки й додайте (merge) їх до основної гілки». Але це не просто запит, а цілий простір для обговорення, перевірки й поліпшення коду перед тим, як він потрапить у main.

2. Стандартний робочий процес із Pull Request

Розберімо покроково, як виглядає типовий робочий процес під час створення нової функціональності.

Перш ніж створювати гілку для нового завдання, переконайтеся, що ви надіслали всі свої завершені коміти (push) і оновили (Update Project) основну гілку main.

Інакше всі ваші «забуті» локальні коміти з main випадково потраплять у новий Pull Request, створивши плутанину для колег.

Крок 1. Створіть гілку для нового завдання.

Як і раніше, будь-яка нова робота починається зі створення окремої гілки. Припустімо, ми хочемо додати до нашого проєкту файл із правилами для контрибʼюторів. Створімо гілку feature/add-contribution-guide.

Крок 2. Внесіть зміни й надішліть свою гілку на GitHub.

У новій гілці створіть файл CONTRIBUTING.md (після створення натисніть Add) і напишіть у ньому повідомлення для інших розробників. Після цього виконайте Commit and Push зі зрозумілим повідомленням, наприклад: docs: Add contribution guide.

Це ключовий крок! Pull Request створюють на основі гілки, яка вже є на віддаленому сервері. Тому, перш ніж створювати PR, потрібно надіслати (push) свою нову гілку на GitHub.

3. Створення Pull Request в IntelliJ IDEA

Тепер, коли ваша гілка вже на GitHub, можна створити Pull Request.

Крок 1. Відкрийте вкладку Pull Requests.

Ліворуч в IDE є вкладка Pull Requests. Відкрийте її й натисніть значок +, щоб створити новий PR.

Крок 2. Заповніть дані для PR.

IDE автоматично відкриє зручний інтерфейс для створення Pull Request. Ваше завдання — грамотно його заповнити. Розберімо основні поля:

1. Заголовок: IDE часто підставляє сюди назву гілки, проте це погана практика. Заголовок має бути коротким, зрозумілим і відображати суть змін — як якісне повідомлення коміту.
2. Опис: тут ви пояснюєте, що і навіщо ви зробили.
3. Ревʼюери: тут ви обираєте одного або кількох колег, які мають перевірити ваш код. У навчальному проєкті пропустимо цей крок, але в реальній роботі він обовʼязковий.
4. Виконавці: зазвичай тут ви вказуєте себе. Це означає, що ви — автор і основні відповідальні за це завдання та за внесення правок після ревʼю.

Після того, як усі поля заповнено, сміливо натисніть Create Pull Request.

4. Код‑ревʼю: перевірка й обговорення

Після створення PR починається найважливіший етап — код‑ревʼю (code review). Колеги можуть відкрити ваш PR, переглянути всі зміни й залишити коментарі.

Ви можете бачити всі обговорення безпосередньо в IDE у вкладці Pull Requests. Якщо хтось залишить коментар, ви отримаєте сповіщення.

Що робити, якщо попросили внести правки?

Це просто. Не потрібно створювати новий PR. Внесіть потрібні зміни в код у тій самій гілці, зробіть новий коміт і надішліть його (push). Pull Request на GitHub оновиться автоматично, додавши нові коміти.

5. Завершення роботи: злиття й видалення гілки

Коли всі зауваження виправлено й команда схвалює ваші зміни, Pull Request можна зливати. Зазвичай це робить старший розробник або ви самі, якщо маєте права.

Крок 1. Merge

Злиття найчастіше відбувається на сайті GitHub. Там під вашим PR зʼявиться велика зелена кнопка Merge pull request. Після натискання ваш код стане частиною основної гілки main.

Крок 2. Видалення гілки.

Після злиття ваша feature‑гілка більше не потрібна, тож її варто видалити, щоб не засмічувати репозиторій. GitHub сам запропонує це зробити, показавши кнопку Delete branch.

Не забудьте також видалити локальну копію гілки у своїй IDE, щоб підтримувати порядок. Це можна зробити через те саме меню керування гілками.

6. Три правила коміту

Якісний коміт — це не лише правильне повідомлення, а й коректний вміст. Щоб історія змін була чистою, корисною та професійною, дотримуйтеся трьох простих правил.

Правило 1: пишіть зрозумілі повідомлення за стандартом

Ваші коміти — це повідомлення, які ви надсилаєте своїй команді та собі в майбутньому. Історія, повна повідомлень fix або update, геть неінформативна. Найпопулярніший стандарт називається Conventional Commits. Він пропонує таку структуру:

<тип>: <короткий опис>

Тип — це коротке слово, що описує категорію ваших змін:

• feat (feature) — для нової функціональності.
• fix — для виправлення помилки.
• docs — для змін у документації.
• style — для правок форматування, що не впливають на логіку коду.
• refactor — для змін у коді, які не додають нову функціональність і не виправляють помилок.
• test — для додавання або виправлення тестів.
• chore — для рутинних завдань, не повʼязаних із кодом (оновлення залежностей, налаштування збірки).

Приклади:

• Погано: fixed bug
• Добре: fix: Correct user login validation

• Погано: readme
• Добре: docs: Update installation instructions

Правило 2: один коміт — одна логічна зміна (атомарність)

Не намагайтеся вмістити в один коміт виправлення вади, додавання нової функціональності та рефакторинг старого коду. Такий коміт складно перевіряти й майже неможливо безболісно відкотити, якщо щось піде не так.

Кожен коміт має розвʼязувати лише одне конкретне завдання.

• Погано: один коміт із повідомленням «Update user page», який додає поле для аватара, виправляє помилку у валідації імені та змінює колір кнопок.
• Добре: три різні коміти:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

Невеликі, сфокусовані коміти значно простіші для розуміння й керування.

Правило 3: коміт не має ламати проєкт

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

Тут на допомогу приходить автоматизація. У цьому курсі ми не налаштовуватимемо автоматичні процеси, але ви маєте знати, як це працює в реальних проєктах. Сучасні команди використовують системи безперервної інтеграції (Continuous Integration, CI), такі як GitHub Actions.

Як це працює?

Ви пишете код і тести до нього. Далі налаштовуєте спеціальний сценарій (workflow) безпосередньо на GitHub. Тепер, щойно ви робите push у свій Pull Request, відбувається таке:

1. GitHub Actions фіксує цю подію й запускає ваш сценарій.
2. Він автоматично «збирає» проєкт і запускає всі тести.
3. Якщо всі тести успішно пройдені, поруч із вашим комітом на GitHub зʼявляється зелена галочка. Це сигнал для всієї команди, що ваші зміни безпечні.
4. Якщо бодай один тест не пройшов, ви побачите червоний хрестик. Зливати такий PR в основну гілку категорично заборонено.

            graph LR
            subgraph GitHub
            A[Розробник] -- "push" --> B(Репозиторій)
            B -- "Подія: push" --> C{GitHub Actions}
            end

            subgraph Workflow
            C -- "Запуск" --> D[Запуск_тестів]
            D --> E[Успішно]
            D --> F[Неуспішно]
            end

            subgraph Notifications
            F --> G((Email))
            G --> H[Розробник]
            G --> I[Команда]
            end

            style F fill:#f99,stroke:#333,stroke-width:2px
            style G fill:#ccf,stroke:#333,stroke-width:2px
        

Можна налаштувати сповіщення. Якщо тести не пройшли, GitHub Actions може надіслати лист вам або всій команді. Такий підхід формує культуру, де тести — не просто формальність, а невідʼємна частина розробки, і кожен несе відповідальність за якість свого коду.