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

У березні Daniel, веброзробник Котокорму, переробляв кнопку оформлення замовлення. Тиждень він працював в окремій гілці (branch) feature/checkout-redesign, і весь цей тиждень робочий сайт лишався таким, як був. До клієнтів нічого не доходило, доки гілку не змерджили в main.

Гілка — це паралельна версія проєкту, окрема лінія комітів. Робота в ній може бути незавершена, експериментальна чи навіть зламана, а main цього не помічає. Саме це дає кільком людям працювати одночасно, не заважаючи одне одному й робочому сайту.

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

Тож просте правило для продакта: сайт показує main. Коміт у fix/checkout-button — справжня робота, видима на GitHub кожному, хто перемкнеться на цю гілку, але клієнти не побачать її, доки її не змерджать у main і не викладуть.

Створення гілки звучить громіздко, ніби Git копіює весь проєкт. Ні. Гілка — це просто назва, що вказує на один коміт, найновіший у своїй лінії. Коли в гілку додають коміт, назва пересувається вперед на нього. Тому гілка створюється миттєво й нічого не коштує.

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

Daniel почав fix/checkout-button від останнього коміту в main, «Update FAQ answers». Відтоді кожен його коміт штовхав назву на крок далі: спершу «Reproduce bug in a test», потім «Re-enable button after cart edits».

У терміналі git switch -c fix/checkout-button створює гілку на поточному коміті й перемикається на неї; на GitHub гілку можна створити в перемикачі гілок, ввівши нову назву. Так чи так нічого не копіюється: з'являється нова назва, і робота починається звідти.

Гілка — це не лише її власні коміти. Вона несе всю історію до коміту, від якого почалася, плюс усе, що в ній додали відтоді.

Візьмімо feature/gift-wrap, яку почали від коміту m2 у main:

• m1 «Add reviews block» і m2 «Fix rating stars» були до початку, тож у гілці вони є;
• g1 «Add gift wrap option» і g2 «Add gift wrap price» — власні коміти гілки;
• m3 «Update footer links» потрапив у main після початку гілки, тож у гілці його немає.

main не чекає, поки хтось працює в гілці. Туди й далі потрапляють інші зміни, і згодом дві лінії відрізняються в обидва боки: у гілці є робота, якої немає в main, а в main — робота, якої немає в гілці.

Коли перемикаєш гілку на feature/gift-wrap, ти бачиш в історії саме m1, m2, g1, g2. Щоб читати такий граф, простеж лінію гілки назад до місця, де вона відходить від main: усе вище цієї точки спільне, усе на відгалуженні належить гілці.

На сторінці репозиторію натисни перемикач гілок — кнопку з написом main. Він показує список гілок, а поле пошуку фільтрує їх за назвою. Вибери fix/checkout-button — і побачиш проєкт таким, яким він є в цій гілці: файли можуть виглядати так само, але на смужці останнього коміту тепер «Re-enable button after cart edits».

Перемикання змінює лише те, що ти бачиш. Воно нічого не редагує, тож завжди безпечне.

Змінюється й адреса. Для папки в ній є /tree/<гілка>/, для файлу — /blob/<гілка>/. Тож посилання на кшталт .../blob/feature/subscription/config/prices.json показує файл із цінами в гілці feature/subscription. Якщо там доставка коштує 69 грн, це пропозиція в гілці, а не ціна, яку платять клієнти. Сайт зміниться, лише якщо цю гілку змерджать у main.

Це класична пастка для нетехнічних людей: хтось надсилає посилання на файл у гілці, і його цитують як «на сайті написано». Завжди перевіряй гілку в перемикачі чи в адресі, перш ніж повторювати цифру.

Під перемикачем гілок GitHub додає підказку на кшталт «This branch is 2 commits ahead of, 1 commit behind main». Обидва числа порівнюють гілку з основною гілкою:

• Ahead: коміти, які є в гілці, але яких немає в main. Це робота, що чекає на мердж.
• Behind: коміти, які є в main, але яких немає в гілці. Це те, наскільки main пішла вперед без гілки.
• Коміти до початку гілки спільні й не входять у жодне число.

Приклад: feature/subscription почалася після c2. У неї є власні s1, s2, s3, а в main відтоді з'явилися c3 і c4. Отже, 3 ahead, 2 behind.

Для продакта обидва числа щось означають. Велике ahead — велика зміна, якій знадобиться рев'ю. Велике behind — гілку будували на старій версії проєкту, тож при зустрічі з сьогоднішньою main можливі сюрпризи. Behind — не катастрофа: розробник може будь-коли підтягнути свіжу main у гілку, наприклад командою git merge main, перебуваючи в гілці. Але що довше чекати, то більше сюрпризів накопичується.

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

Сторінка розкладає гілки по вкладках. В Active — гілки зі свіжими комітами. У Stale, тобто застарілих, — ті, куди ніхто не комітив приблизно три місяці. Тож гілка, яку востаннє чіпали 4 чи 7 місяців тому, застаріла; а та, що оновлювалася 2 дні, 3 тижні чи 2 місяці тому, ще активна.

У Котокормі цей список розповідає історію. content/delivery-copy показує, що контент-маркетологиня Emma тепер тримає тексти в репозиторії. А feature/loyalty-points — 12 ahead, 86 behind і п'ять місяців без змін: офіційно призупинена, а чесно — покинута, і змерджити її тепер було б боляче.

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

Назви гілок у Котокормі мають закономірність: fix/, feature/, content/. Це не правило GitHub чи Git, а звичка команди. Сам Git дозволяє майже будь-яку назву. Звичка корисна тим, що тип роботи можна вгадати ще до того, як відкриєш гілку, а список гілок читається як короткий перелік поточних задач.

Звична форма — префікс/опис, малими літерами, з дефісами замість пробілів:

• fix/cart-total-rounding: виправлення бага;
• feature/gift-cards: нова функціональність;
• docs/setup-guide: документація, а не сам сайт;
• content/delivery-copy: тексти.

Трапляються й інші стилі: номер issue на початку, як-от 142-delivery-map (робота над issue #142), або ім'я автора, як-от daniel/checkout-button. Деякі назви генерує сам GitHub: revert-97-feature/checkout-redesign створила кнопка Revert, щоб скасувати pull request #97.

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

Добра назва гілки одразу відповідає на два питання: що це за робота і про що вона. Префікс дає тип (fix/, feature/, content/, docs/), а кілька слів після нього — тему.

Опис має бути коротким і конкретним: fix/promo-code-spaces, а не fix/bug чи fix/the-promo-code-field-on-checkout-rejects-codes-with-spaces. Малі літери й дефіси; пробіли в назвах гілок Git узагалі не дозволяє, а великі літери на деяких комп'ютерах плутають.

Префікс вибирають за природою зміни, а не за важливістю. Баг у наявному полі — це fix, навіть якщо він терміновий; нова опція для клієнтів — feature. Якщо команда пов'язує гілки з issues, номер іде першим: 151-promo-code-spaces.

Чому це важливо продакту? Назви гілок трапляються в pull requests, на сторінці гілок і в посиланнях, які тобі надсилають. Коли вони тримаються однієї звички, можна проглянути список із двадцяти гілок і зрозуміти, що зараз у роботі, нічого не відкриваючи.

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

Слово «видалити» лякає після всієї роботи, але видалення гілки прибирає назву, а не роботу. Щойно зміни змерджено, вони живуть в історії main. Назва гілки була лише вказівником, і свою задачу вона виконала.

Після мерджу GitHub пропонує на сторінці pull request кнопку Delete branch. Якщо гілка комусь знову знадобиться, на тій самій сторінці є Restore branch. Багато команд вмикають у налаштуваннях репозиторію автоматичне видалення змерджених гілок, як і Котокорм; інакше список гілок перетворюється на горище. Розробники роблять те саме в терміналі через git branch -d fix/footer-links, і ця команда відмовляється видаляти гілку, чию роботу ще не змерджено.

Короткі гілки ще й безпечніші. Що менше часу гілка проводить окремо від main, то менше сюрпризів, коли вона повертається, і то менший pull request комусь доведеться переглядати.

Ось як Daniel зламав оформлення замовлення в березні. Він відгалузився від main, зробив три коміти й усе перевірив у своїй гілці. Тим часом у main змерджили панель із повідомленням про cookie від колеги. Його гілка відставала на один коміт, а він і не глянув.

Тож він перевіряв версію сайту з новою кнопкою, але без панелі cookie. Після мерджу в main уперше опинилося і те, і те. На телефонах панель лягла просто на кнопку, натиснути її не міг ніхто, і за десять хвилин команда відкотила мердж.

Git не заперечував, бо дві гілки змінювали різні файли. Git зупиняє мердж, лише коли дві гілки змінюють ті самі рядки; він не може знати, що дві окремі зміни конфліктують на екрані телефона.

Звідси два висновки. Перед мерджем перевір behind, підтягни свіжу main у гілку й протестуй ще раз. І тримай гілки короткоживучими, щоб менше пропускати з main. Редизайн повернувся за кілька днів з оновленої гілки й відтоді працює.