Під час навчання у Flatiron School я працював із Git: я форкував (forking) у лабораторних роботах, здавав завдання по коду та брав участь у групових проєктах. Однак я так і не до кінця розумів, що саме роблять ці команди та як Git зберігає внесені в мої репозиторії зміни. У цьому блозі я хочу поділитися тим, що дізнався про різні типи гілок (branches) у Git. Сподіваюся, це допоможе й вам краще розібратися, якщо ви також лише починаєте працювати із системами керування версіями (Version Control Systems).
Зображення з: https://www.perforce.com/blog/vcs/git-branching-model-multiple-releases
Що таке гілка Git?
Згідно з офіційною документацією Git, гілкування (branching):
«Гілкування означає, що ви відхиляєтесь від основної лінії розробки та продовжуєте працювати, не заважаючи на неї.»
Тобто створюється нова копія основного репозиторію, яка відгалужується від початкового шляху, і її можна змінювати без впливу на оригінальну гілку (main). Існує чимало стратегій гілкування, які застосовують у різних проєктах, адже кожна має власні переваги й краще пасує до певних робочих процесів. Щоб створити гілку, введіть:
git branch
git checkout
Ця послідовність команд створює нову гілку та переключає ваші коміти з основної гілки на щойно створену. Коли зміни готові для публікації в основній гілці, ми виконуємо злиття (merge). Для цього потрібно перейти до потрібної гілки й запустити команду злиття так:
git checkout main
git merge
Отже, ознайомившись із тим, що таке гілка та як її створювати й зливати, розгляньмо кілька популярних стратегій гілкування, які застосовують в індустрії.
Розробка на основі основної гілки (Trunk-Based Development)
Цей підхід є найпростішим способом співпраці в Git. Як випливає з назви, розробка ведеться безпосередньо в «основній» або «головній» (trunk) гілці, без створення довгострокових додаткових гілок.
Зображення з: https://www.optimizely.com/optimization-glossary/trunk-based-development/
Попри простоту та зручність, цей підхід вимагає від команди максимальної уважності та дисципліни. Оскільки зміни вносяться прямо в основну гілку, навіть незначна помилка може спричинити серйозні проблеми порівняно з більш «захищеними» методами. Один зі способів зменшити цей ризик — проводити суворе тестування та аналіз перед впровадженням змін.
Ключова складова розробки на основі основної гілки — це безперервне розгортання (Continuous Deployment). Воно автоматизує розгортання застосунку: після успішного проходження автоматизованих тестів зміни одразу розгортаються з новим оновленням. Основна перевага такого процесу полягає в його ефективності, стабільності та можливості частіше вносити невеликі зміни замість очікування великого релізу.
Гілкування за ознакою функціональності (Feature Branching)/Github Flow
Гілкування за ознакою функціональності (Feature Branching) — ще одна досить проста стратегія, яка краще захищає головну гілку, доки зміни в окремій гілці не буде схвалено через запит на внесення змін (pull request).
Зображення з: https://build5nines.com/introduction-to-git-version-control-workflow/
За цієї стратегії кожна нова функція розробляється в окремій гілці, яку спершу розглядають і обговорюють через запит на внесення змін (pull request), а потім тестують і зливають з основною гілкою. Зазвичай цикл розробки тут короткий: гілка відповідає за невеликі зміни, які можуть бути виконані за кілька годин чи день.
Зазвичай у межах цієї стратегії застосовують безперервну доставку (Continuous Delivery), схожу на безперервне розгортання (Continuous Deployment), але автоматизація зупиняється перед виходом у продакшн. Це забезпечує додатковий захист від помилок, що можуть прослизнути крізь тести. Хоча такий підхід «безпечніший», він потребує більше часу й може спричинити затримки порівняно з безперервним розгортанням (Continuous Deployment).
Стратегія форкування (Forking Strategy)
Цей метод нагадує гілкування за ознакою функціональності, однак замість створення окремих гілок для кожної функції користувачі форкують (fork) основний репозиторій. У форкнутій копії (її також називають origin) розробники вносять потрібні зміни, а коли досягають бажаного результату, надсилають запит на внесення змін (pull request) для злиття оновленої копії з основною гілкою.
Зображення з: https://www.tomasbeuzen.com/post/git-fork-branch-pull/
Ця стратегія найчастіше застосовується у відкритому програмному забезпеченні (open source software), де будь-хто може отримати доступ до коду й запропонувати правки чи покращення, не входячи до основної команди розробників. Головна перевага цього методу в тому, що лише команда розробників проєкту контролює оригінальний репозиторій і може схвалювати або відхиляти запропоновані зміни. Це дає змогу заохочувати внесок зовнішніх учасників, водночас зберігаючи основний продукт у безпеці від потенційно шкідливих правок.
Гілкування для релізів (Release Branching)
Гілкування для релізів подібне до гілкування за ознакою функціональності, проте замість короткотривалих гілок для невеликих змін релізні гілки охоплюють масштабніші правки й існують значно довше.
Зображення джерела: http://releaseflow.org/
Ця стратегія добре пасує для рідкісних розгортань або нечастих оновлень. Оскільки релізні гілки існують довше й охоплюють більше змін, на їх вихід у продакшн витрачається більше часу. Окрім того, процес ускладнюється через можливі проблеми в комунікації між командами, які паралельно працюють над різними довгостроковими змінами. Якщо ці гілки не синхронізувати з основною, можуть виникати конфлікти злиття (merge conflicts). Зрештою, через повільність і складність цей метод не є оптимальним для більшості проєктів.
Git Flow
З цією стратегією гілкування Git flow ситуація стає ще складнішою.
Поряд з основною гілкою створюється гілка для розробки, яка працює паралельно з основною. Замість того, щоб створювати гілки для функцій та релізів від основної гілки, як це було раніше, вони створюються від гілки для розробки.
Зображення з: https://www.campingcoder.com/2018/04/how-to-use-git-flow/
Через таку складність Git Flow надає високий рівень безпеки, проте вимагає чимало часу й регулярних оновлень. Ця стратегія підходить лише для дуже великих проєктів і компаній, де створення гілок, керування всіма запитами на внесення змін (pull requests) та обробка злиттів можуть бути окремою роллю. Такий підхід виправданий тільки для великих команд, що працюють із великими обсягами даних і потребують тотального ручного контролю.
Висновок
Як бачите, способів організувати гілкування у спільних проєктах із Git справді багато. Визначити, який метод підійде саме вам, може бути непросто, тому зазвичай варто тримати структуру якомога простішою та робити невеликі, ефективні зміни. Хоча розробка на основі основної гілки (Trunk-Based Development) приваблює своєю простотою, вона залишає дуже мало простору для помилок. А стратегія Git Flow виявиться надто складною для маленького проєкту з двома учасниками. Ідеальний підхід — обрати таку модель, що лишається простою, але водночас захищає основну гілку від помилок і потенційних «провалів» у коді.
Перекладено з: Understanding Git Branching