Магія 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 у свою гілку, відбувається магія:

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

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

            subgraph Сценарій
            C -- "Запуск" --> D[Запуск_тестів]
            D --> E[Успішно]
            D --> F[Невдало]
            end

            subgraph Сповіщення
            F --> G((Електронна_пошта))
            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 може надіслати лист вам або всій команді. Такий підхід формує культуру, у якій тести — не формальність, а невідʼємна частина розробки, і кожен відповідає за якість свого коду.