Git-стратегія гілкування

Час життя гілки — це і є вся суть

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

Пастка в тому, що витрата невидима, поки накопичується. Гілка, відкрита три тижні, кожен із цих днів відчувається продуктивною; ціна приходить одразу при злитті — як розв’язання конфліктів, якого ніхто не оцінював, і регресія, якої ніхто не передбачав. Саме тому довгоживучі гілки й болісна інтеграція — це одна проблема, описана двічі.

Чотири моделі, які вам трапляться

• Trunk-based

  Усі комітять в одну головну гілку через короткі гілки, що живуть години, а не дні. Незавершена робота ховається за прапорцями, а не в гілці. Production — це тег або деплой із main.

• GitHub Flow

  Одна головна гілка плюс гілка на зміну, що зливається через pull request, деплой із main. Прагматична середина й типовий вибір більшості продуктових команд — trunk-based із доданим рев’ю.

• GitLab Flow

  GitHub Flow плюс низхідні гілки, що віддзеркалюють середовища (staging, production) або версії. Зміни завжди течуть в один бік, main → нижче, тож середовище ніколи не міститиме того, чого немає в main.

• GitFlow

  Довгоживучі гілки develop, release і hotfix поруч із main. Створений для версійованого софту з кількома підтримуваними релізами «в полі» — і має відповідну ціну.

Важливе уточнення, бо GitFlow досі викладають як стандарт: його автор додав до оригінального допису 2010 року примітку, що модель створювалася для софту з явними версійованими релізами, і що командам, які роблять вебзастосунки з безперервною поставкою, не варто її брати. Вона ніколи не була хибною — вона відповідала на питання, якого більшість вебкоманд уже не має.

GitLab Flow варто знати, бо саме до нього зазвичай тягнуться, коли GitHub Flow перестає пасувати: коли є staging, який має бути рівно на крок позаду production, або клієнт на старішій версії. Його єдине правило запобігає класичній катастрофі — виправленню, внесеному прямо в production-гілку й ніколи не влитому назад, яке тихо повертається багом у наступному релізі.

Як обрати між ними

Чесне правило вибору коротке. Якщо ви підтримуєте рівно одну версію в production, беріть найкоротші гілки, які витримає ваш набір тестів. Якщо ви підтримуєте кілька версій одночасно — on-premise продукт, мобільний застосунок із користувачами на старих збірках, прошивка, — вам справді потрібні релізні гілки, і GitFlow тут розумна відповідь, а не спадкова звичка.

Варто знати ціну цієї відповіді, перш ніж на неї погодитися. Кожна підтримувана версія — це гілка, до якої виправлення безпеки треба застосувати окремо, окремо протестувати й окремо випустити. Три підтримувані версії означають, що кожен терміновий патч — це три cherry-pick, три прогони тестів і три релізи, а виправлення, правильне на main, іноді не лягає чисто на дворічну гілку. Ця робота і є справжньою ціною релізних гілок, і на жодній схемі моделі її не видно.

Що робить короткі гілки можливими

Команди рідко обирають довгі гілки навмисно. Вони опиняються з ними, бо щось робить раннє злиття неможливим, а винною призначають модель. Справжньою причиною зазвичай є одна з трьох речей.

Затримка рев’ю і розмір зміни

Якщо pull request чекає на рев’юера півтора дня, ніхто не відкриває маленьких: вартість одного оберту фіксована, тож раціонально запхати в кожен більше. Від цього рев’ю стають більшими, а отже повільнішими, а отже пакувати стає ще вигідніше. Петля сама себе підсилює, і це найпоширеніша причина, чому команді не вдається скоротити життя гілки.

Виправлення непоказні: заявлене очікування щодо часу відповіді на рев’ю, виміряне в годинах; розмір, за якого рев’юер має право попросити поділити; і парна чи ансамблева робота для змін, які інакше були б завеликими для рев’ю взагалі. Зверніть увагу: trunk-based не скасовує рев’ю — він його переміщує: або в парну роботу в реальному часі, або в рев’ю, достатньо швидке, щоб процес не вигинався навколо нього.

Великі зміни без великих гілок

Звична заперечна теза проти коротких гілок — великий рефакторинг: заміна платіжного провайдера, зміна ORM, перебудова модуля. Branch by abstraction — техніка-відповідь: ввести інтерфейс перед тим, що замінюють, перевести на нього викликів по одному злиттю, збудувати за ним нову реалізацію, перемкнути, потім видалити стару. Кожен крок — мала, безпечна, окремо злитна зміна, і кодова база придатна до релізу на кожному з них.

Merge, rebase чи squash

Ця суперечка з’їдає більше енергії команди, ніж заслуговує, тож коротко. Merge-коміт зберігає рівно те, що сталося, включно з тим, що дві лінії роботи існували паралельно; на активному репозиторії з короткими гілками це дає історію точну й важку для читання. Rebase переграє ваші коміти поверх поточного транка й дає лінійну історію — ціною переписування комітів, що нормально на власній гілці й шкідливо на спільній. Squash згортає гілку в один коміт, тож історія транка читається як одна зміна на одиницю роботи, а проміжні кроки зникають.

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

Як це виявляється в реальній поставці

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

Де вона вироджується

• Фіче-гілка, відкрита місяць, — злиття стає окремим проєктом.
• GitFlow, узятий для вебзастосунку з однією живою версією, додає церемонію, що нікому не служить.
• Гілка на кожного розробника перетворює інтеграцію на періодичні перемовини.
• Хотфікс, застосований до production-гілки й не влитий назад, повертається багом.
• Короткі гілки без прапорців — недороблене або зливають зламаним, або тримають осторонь.
• Переписування історії спільної гілки ламає всіх, хто збудував на ній роботу.

Коли це застосовувати

Пов’язані сторінки

• МенеджментПланування релізуПланування релізу — це рішення про те, що потрапляє до користувачів, коли і як ви дізнаєтесь, що щось пішло не так. Найкорисніший крок у плануванні релізу — перестати вважати деплой і реліз однією подією. На цій сторінці — це розділення, чотири стратегії викочування, чотири види feature flag, чому відкат часто недоступний і що вимірювати.
• МенеджментChangelogChangelog — це впорядкований, зрозумілий людині запис того, що змінилося в кожному релізі. Уся його цінність — у тому, що він написаний для читача, який вирішує, чи оновлюватися. Саме тому згенероване звалище комітів, хай навіть повне, не є changelog. На цій сторінці — шість заголовків, що обіцяє номер версії, депрекація і як далеко чесно може завести автоматизація.
• МенеджментAgileAgile — це спосіб створювати софт, який припускає, що ви в чомусь помиляєтесь, і планує дізнатися про це рано. Agile не є процесом, який «встановлюють», і не є набором зустрічей — це невелика група переконань, записаних 2001 року, на яких побудовано з десяток різних методологій. На цій сторінці ми розберемо ці переконання, усі дванадцять принципів за ними і те, що насправді змінюється в команді, яка сприймає їх серйозно.