Магія Pull Request

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

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

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

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

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

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

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

Інакше всі ваші «забуті» локальні коміти з 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 знайдіть вкладку (Tool Window) Pull Requests. Відкрийте її й натисніть значок + (або кнопку Create Pull Request), щоб створити новий PR.

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

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

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

Коли всі поля буде заповнено, сміливо натискайте Create Pull Request.

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

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

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

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

Усе просто! Не потрібно створювати новий PR. Просто внесіть потрібні зміни до коду у своїй поточній гілці, зробіть новий коміт і надішліть його. Pull Request на GitHub автоматично оновиться й додасть ваші нові коміти до наявного обговорення.

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

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

Крок 1. Злиття (Merge).

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

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

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

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

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

Якщо в запалі роботи ви змінили надто багато всього в одному файлі, IntelliJ IDEA дозволяє включити до коміту не весь файл цілком. У вікні Commit ви можете розгорнути файл і поставити галочки лише навпроти тих фрагментів коду (chunks), які належать до конкретної логічної задачі.

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

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

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

Як це працює?

Ви пишете код і тести до нього. Потім ви або DevOps налаштовуєте спеціальний сценарій (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 може надіслати листа вам або всій команді. Такий підхід формує культуру, у якій тести — не просто формальність, а невідʼємна частина розробки. І кожен несе відповідальність за якість свого коду.