Модуль 9 · урок 2 з 9

Гілки

Гілка — це паралельна лінія розробки. Правила іменування виглядають бюрократією, поки в репозиторії три гілки. При тридцяти вони стають єдиним способом зрозуміти, що взагалі відбувається.

Іменування

feature/12-status-filter        # нова функціональність
bugfix/45-empty-state-flash    # виправлення бага
hotfix/51-login-crash          # термінове виправлення в проді
refactor/18-task-store         # без зміни поведінки
chore/22-update-deps           # службове: залежності, конфіги
docs/30-api-contract           # документація

Формула проста: тип / номер задачі / короткий опис англійською. Кожна частина має сенс — тип каже, чого чекати від змін; номер веде до задачі; опис дає зрозуміти, про що гілка, не відкриваючи її.

Чому англійською й через дефіс

Кирилиця в назві гілки технічно можлива, але ламається в частині інструментів і незручна в консолі. Пробіли неприпустимі. Тому усталений формат — lowercase-with-dashes. Це не смак, а сумісність.

Основні команди

git switch -c feature/12-status-filter        # створити й перейти (сучасний варіант)
git checkout -b feature/12-status-filter      # те саме, класичний варіант

git switch main                               # перейти на наявну
git branch                                    # список локальних
git branch -a                                 # включно з віддаленими

git push -u origin feature/12-status-filter   # перший push із привʼязкою
git push                                      # наступні

git branch -d feature/12-status-filter        # видалити злиту
git branch -D feature/12-status-filter        # видалити примусово

Від чого гілкуватись

# ✅ завжди від свіжої основної гілки
git switch main
git pull
git switch -c feature/12-status-filter

# ❌ від своєї попередньої гілки — потім у PR будуть чужі зміни

Класична помилка новачка: почати нову задачу, не перемкнувшись на main. Тоді в PR потрапляють коміти з попередньої гілки, рев'ювер бачить сорок файлів замість трьох і просить «розберись, будь ласка». Дві команди на початку рятують від цього повністю.

Скільки жити гілці

Тривалість	Що з нею стається
1–2 дні	Норма. Конфліктів майже не буває, рев'ю швидке
Тиждень	Уже болить: основна гілка пішла вперед, з'являються конфлікти
Місяць	Мердж перетворюється на окремий проєкт; частину роботи легше переписати

Правило маленьких гілок

Якщо задача велика — розбий її на кілька гілок і кілька PR. «Додати грид» — це три задачі: таблиця з даними, сортування, фільтри. Три PR по двісті рядків рев'юяться за пів години сумарно. Один PR на шістсот рядків не рев'ює ніхто — його або пропускають не читаючи, або він висить три дні.

Що робити з навчальним проєктом

# гілка на кожен урок або блок практики
feature/m5-grid-sorting
feature/m6-task-form-modal
refactor/m4-extract-store

# у main лишається лише те, що працює

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

≈ 25 хв · +25 XP за урок