Магія Pull Requests

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

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