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