# Гілки в Git: паралельні версії проєкту

> Що таке гілка в Git (git branch), чому робота йде в короткоживучих гілках поруч із main і як читати гілки на GitHub: перемикач гілок, ahead і behind, застарілі гілки, правила назв і графи з кількома доріжками.

- Курс: [Git і GitHub для продактів](https://productovi.com/uk/courses/git-for-product.md)
- Модуль: Гілки та мерджі
- Урок 4/15, ~34 хв
- Джерело: https://productovi.com/uk/courses/git-for-product/branches

## Тиждень роботи, якого сайт не бачив

**Alex Tutor:** Знову в продуктовій команді Котокорму, і в тебе є питання до Daniel, одного з розробників сайту.

**Sofia:** Daniel, мушу спитати. Як саме ти зламав кнопку оформлення замовлення?

**Daniel:** Справедливе питання. У березні я її переробляв. Тиждень працював в окремій **гілці** (branch), `feature/checkout-redesign`, і весь цей тиждень робочий сайт лишався таким, як був.

**Sofia:** Тобто нічого з того, що ти робив у гілці, до клієнтів не доходило?

**Daniel:** Нічого, доки гілку не змерджили в `main`. Отоді кнопка й зламалася, а за десять хвилин ми відкотили мердж. У подробицях зізнаюся наприкінці уроку.

**Alex Tutor:** Це і є сьогоднішня тема: що таке гілка в Git? **Гілка** (branch) — це паралельна версія проєкту, окрема лінія комітів. Робота в ній може бути незавершена чи навіть зламана, а `main` цього не помічає.

![Від основної колії відходить бічна; у депо робітник збирає й випробовує новий вагон, а потяги на основній колії й далі прибувають на станцію.](https://productovi.com/courses/git-for-product/inline/branches-illustration-2.webp)

*Незавершена робота живе на своїй лінії, доки її не змерджать в основну гілку.*

**Alex Tutor:** `main` теж гілка: **основна гілка**, або гілка за замовчуванням (default branch). GitHub відкриває її першою, і саме її в Котокормі викладають на сайт. У старіших репозиторіях вона часто називається `master`.

> **Вправа:** Daniel додає новий коміт у `fix/checkout-button`. Клієнти на сайті Котокорму одразу бачать цю зміну.

## Назва, яка рухається

**Sofia:** Коли Daniel створює гілку, GitHub копіює весь проєкт? Звучить громіздко.

**Alex Tutor:** Нічого не копіюється. Гілка це просто назва, яка вказує на один коміт, найновіший у своїй лінії. З'являється новий коміт, і назва пересувається на нього.

**Alex Tutor:** Порівняй із тегом із першого модуля. Тег назавжди лишається на своєму коміті. А назва гілки рухається далі, доки в гілку додають коміти.

**Alex Tutor:** Швидка перевірка щодо цієї рухомої назви, перш ніж дивитися на гілку Daniel.

> **Вправа:** Daniel додає новий коміт у `fix/checkout-button`. Що відбувається з назвою гілки?

**Alex Tutor:** Ось над чим Daniel працює просто зараз. Підтримка повідомила про баг: після зміни кошика кнопка оформлення замовлення лишається сірою. Він почав гілку `fix/checkout-button` від останнього коміту в `main`.

```text
Граф комітів, від найстарішого: main і гілка fix/checkout-button
1. коміт e7c3b19 у main "Add summer promo banner"
2. коміт f02a6d4 у main "Update FAQ answers"
3. гілка fix/checkout-button починається від коміту f02a6d4
4. коміт 3a9d1c4 у fix/checkout-button "Reproduce bug in a test"
5. коміт 8be2f70 у main "Add cat treats bundle"
6. коміт b7e4a05 у fix/checkout-button "Re-enable button after cart edits" (виділено)
```

*Гілка починається від f02a6d4 і має два власні коміти. 8be2f70 потрапив у main уже після початку гілки.*

**Sofia:** Дві доріжки. Ліва це `main`. Права відгалужується від «Update FAQ answers» і має два власні коміти.

**Alex Tutor:** Так. І зверни увагу, що `main` не чекала: поки Daniel працював, туди потрапив «Add cat treats bundle». Тепер дві лінії відрізняються в обидва боки.

> **Вправа:** Ти перемикаєш гілку на `feature/gift-wrap`. Які коміти є в історії цієї гілки? Познач усе, що підходить.

## Перемикаємо гілки на GitHub

**Alex Tutor:** Тепер знайди це на GitHub. На сторінці репозиторію натисни перемикач гілок, кнопку з написом `main`. Він показує список гілок, а поле пошуку фільтрує їх за назвою.

**Sofia:** Вибираю `fix/checkout-button`. Список файлів начебто той самий, але на смужці останнього коміту тепер «Re-enable button after cart edits».

**Alex Tutor:** Ти бачиш проєкт таким, яким він є в цій гілці. Змінилася й адреса: тепер у ній є `/tree/fix/checkout-button`. Перемикання змінює лише те, що ти бачиш. Воно нічого не редагує.

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

**Alex Tutor:** Під перемикачем GitHub додає підказку. Станом на 2026 рік вона звучить приблизно так: «This branch is 2 commits ahead of, 1 commit behind `main`».

> **Вправа:** Колега надсилає тобі посилання на `config/prices.json`. В адресі є `/blob/feature/subscription/`, а у файлі написано, що доставка коштує 69 грн. Який висновок правильний?

## Ahead і behind

**Sofia:** Ahead і behind... відносно чого?

**Alex Tutor:** Відносно основної гілки. **Ahead** рахує коміти, які є в гілці, але яких немає в `main`: два коміти від Daniel. **Behind** рахує коміти, які є в `main`, але яких немає в гілці: той самий набір котячих ласощів.

**Sofia:** Тобто ahead це робота, яка чекає на мердж, а behind показує, наскільки `main` пішла вперед без цієї гілки.

**Alex Tutor:** Саме так. Велике число ahead означає велику зміну, якій потрібне рев'ю. Велике число behind означає, що гілку будували на старій версії проєкту.

**Daniel:** Behind це не катастрофа. Я можу будь-коли підтягнути свіжу `main` у свою гілку. Але що довше чекаю, то більше накопичується сюрпризів.

> **Вправа:** Що GitHub покаже для `feature/subscription` порівняно з `main`?

## Сторінка гілок: активні й застарілі

**Alex Tutor:** Поруч із перемикачем є лічильник гілок. Натисни його або `View all branches` у самому перемикачі, і відкриється сторінка гілок: кожна гілка з датою останнього оновлення, числами behind і ahead та своїм pull request.

**Alex Tutor:** Сторінка розкладає гілки по вкладках. В `Active` гілки зі свіжими комітами. У `Stale`, тобто застарілих, ті, де комітів не було приблизно три місяці.

```text
Гілки catchow/website
- [Branch] main: Основна гілка. Оновлено вчора
- [Branch] feature/free-delivery-1000: Оновлено 3 години тому · 0 behind, 3 ahead
- [Branch] fix/checkout-button: Оновлено вчора · 1 behind, 2 ahead
- [Branch] content/delivery-copy: Оновлено минулого тижня · 2 behind, 1 ahead
- [Branch] feature/loyalty-points: Оновлено 5 місяців тому · 86 behind, 12 ahead
```

**Sofia:** `content/delivery-copy` це ж гілка від Emma! Отже, наша контент-маркетологиня таки перенесла свої тексти в репозиторій.

**Alex Tutor:** Твоя записка з першого модуля спрацювала. А тепер подивись на останній рядок.

**Sofia:** `feature/loyalty-points`: дванадцять комітів ahead, 86 behind, і п'ять місяців ніхто не чіпав. Це покинутий проєкт?

**Daniel:** Офіційно призупинений. А якщо чесно, покинутий. Змерджити його зараз було б боляче: відтоді `main` надто змінилася.

**Alex Tutor:** Для продакта застаріла гілка це привід спитати: ця робота ще в планах? Якщо ні, команда може видалити гілку й закрити тему.

![Заросла бур'яном бічна колія із запиленим покинутим вагоном лишилася далеко позаду жвавої основної лінії, де пролітають нові потяги.](https://productovi.com/courses/git-for-product/inline/branches-illustration-3.webp)

*Застаріла гілка — продуктове питання: чи ця робота ще в планах?*

> **Вправа:** Які з цих гілок GitHub покаже у вкладці `Stale`? Познач усе, що підходить.

## Правила назв гілок: що каже назва

**Sofia:** У назвах є закономірність: `fix/`, `feature/`, `content/`. Це правило GitHub?

**Daniel:** Ні, це звичка команди. Префікс каже, що це за робота, а решта пояснює, про що вона. Малі літери, дефіси замість пробілів. Сам Git дозволяє майже будь-яку назву.

**Daniel:** Трапляються й інші стилі: номер issue на початку, як-от `131-checkout-button`, або ім'я автора, як-от `daniel/checkout-button`. І назви, які GitHub генерує сам, наприклад `revert-97-feature/checkout-redesign`.

**Sofia:** Остання це ж твій десятихвилинний порятунок у березні, правда?

**Daniel:** Визнаю. Цю гілку за мене створила кнопка `Revert`.

**Alex Tutor:** Ще один шаблон на потім: префікси `hotfix/` і `release/` належать до git flow, воркфлоу, який ми порівняємо з нашим у четвертому модулі.

> **Вправа:** Зістав кожну назву гілки з тим, що вона найімовірніше означає.

**Alex Tutor:** А тепер навпаки: є задача, вибери назву.

> **Вправа:** Підтримка повідомляє про баг: поле промокоду не приймає коди з пробілами. Daniel виправлятиме це. Яка назва гілки найкраще відповідає звичкам Котокорму?

## Коротке життя і тихий кінець

**Alex Tutor:** Здорові гілки живуть дні, а не місяці. Одна гілка, одна задача: почати від свіжої `main`, зробити кілька комітів, відкрити pull request, змерджити, видалити.

**Sofia:** Видалити? Після всієї цієї роботи?

**Alex Tutor:** Видалення гілки прибирає назву, а не роботу. Щойно зміни змерджено, вони живуть у `main`. Назва гілки була лише вказівником, і свою задачу вона виконала.

![Здорова гілка починається від свіжої main, отримує кілька комітів, проходить pull request, мерджиться й видаляється: назва зникає, робота лишається в main.](https://productovi.com/courses/git-for-product/diagrams/m2-l1-branch-lifecycle-uk.png)

![Робітник висмикує невеликий вказівник там, де бічна стежка вже влилася в широку бруковану дорогу; дорога тягнеться далі неушкоджена.](https://productovi.com/courses/git-for-product/inline/branches-illustration-4.webp)

**Alex Tutor:** Після мерджу GitHub пропонує на сторінці pull request кнопку `Delete branch`. А якщо гілка комусь знову знадобиться, на тій самій сторінці є `Restore branch`.

**Daniel:** Багато команд вмикають у налаштуваннях репозиторію автоматичне видалення змерджених гілок. Ми теж. Інакше список гілок перетворюється на горище.

> **Вправа:** Pull request змерджено, і Daniel натискає `Delete branch`. Що станеться з виправленням із коміту f1?

## Зізнання від Daniel

**Alex Tutor:** Час для зізнання від Daniel, і одразу з графом. Це березень: ліворуч `main`, праворуч його гілка з редизайном.

```text
Граф комітів, від найстарішого: Березень: редизайн кнопки перед мерджем
1. коміт 4d2a8e1 у main "Add order tracking link"
2. гілка feature/checkout-redesign починається від коміту 4d2a8e1
3. коміт 61b9f3c у feature/checkout-redesign "New checkout button styles"
4. коміт d18e6a0 у main "Add cookie notice bar (#95)" (виділено)
5. коміт 92c4b1f у feature/checkout-redesign "Move button to sticky footer"
6. коміт 0a7f5e3 у feature/checkout-redesign "Update button texts"
```

*Гілка на 3 коміти ahead від main і на 1 behind: у ній немає панелі з повідомленням про cookie.*

**Daniel:** Я відгалузився, зробив три коміти й усе перевірив у своїй гілці. Тим часом у `main` змерджили панель із повідомленням про cookie від колеги. Моя гілка відставала на один коміт, а я й не глянув.

**Sofia:** Тобто ти перевіряв версію сайту, де була твоя нова кнопка, але не було панелі cookie.

**Daniel:** Саме так. Після мерджу в `main` уперше опинилося і те, і те. На телефонах панель лягла просто на мою кнопку, і натиснути її не міг ніхто. Звідси й відкат.

**Alex Tutor:** Git не мав жодних заперечень, бо дві гілки змінювали різні файли. Ось чому на «behind» варто глянути перед мерджем і чому короткоживучі гілки безпечніші.

**Daniel:** Редизайн повернувся за кілька днів, уже з гілки, оновленої свіжою `main`. Відтоді працює.

> **Вправа:** Які твердження про цей граф правдиві? Познач усе, що підходить.

## Поясни підтримці

**Alex Tutor:** Останнє завдання. Підтримка пише: «Daniel каже, що виправлення кнопки готове, і я бачу його коміти на GitHub. Чому в клієнтів кнопка досі сіра?»

**Sofia:** Бо коміти лежать у `fix/checkout-button`, на два попереду `main`, а сайт показує `main`.

**Alex Tutor:** А тепер скажи це без слів «гілка» і «коміт». Два-три речення, які підтримка зможе передати далі.

**Daniel:** І не обіцяй дати. Виправлення ще має пройти рев'ю.

> **Вправа:** Підтримка питає: «Daniel каже, що виправлення кнопки готове, і я бачу його коміти на GitHub. Чому в клієнтів кнопка досі сіра?» Виправлення лежить у `fix/checkout-button`, на 2 коміти ahead від `main`, і ще не змерджене. Напиши відповідь для підтримки на 2–3 речення без Git-жаргону.

**Alex Tutor:** Наступного уроку: що саме відбувається, коли гілку зливають, і чому кнопка мерджу на GitHub має три варіанти.

**Sofia:** Три способи натиснути одну кнопку. Ну звісно.

- Попередній урок: [Читаємо історію: повідомлення, diff і blame](https://productovi.com/uk/courses/git-for-product/reading-history-diffs-and-blame.md)
- Наступний урок: [Злиття (git merge): мердж-коміт, squash і rebase на GitHub](https://productovi.com/uk/courses/git-for-product/merging.md)

---
Productovi Learning. Безкоштовно, читати можна без реєстрації.