Гілки та стратегії гілкування
в Git дають змогу відгалузитися від головної лінії розробки і працювати незалежно, не зачіпаючи основну кодову базу. Це як власний паралельний всесвіт, де можна експериментувати, розробляти нові функції чи виправляти помилки, не заважаючи стабільній версії проєкту.
Почнімо з того, що виведемо список усіх гілок у репозиторії. Для цього є команда без аргументів.
Виведи список усіх гілок командою git branch.
Якщо обійшлося без таємних експериментів, у списку буде лише одна гілка — гілка за замовчуванням main. Вона завжди створюється під час ініціалізації нового репозиторію.
Гілки — це просто вказівники на коміти. Є ще один вказівник, HEAD: він вказує на коміт, який зараз розгорнутий у робочому дереві. Зазвичай це останній коміт гілки. Коли ти створюєш новий коміт, вказівник гілки пересувається на нього, як і HEAD. Коли перемикаєшся на іншу гілку, HEAD переходить на останній коміт нової гілки.
Тепер перейдімо до стратегій гілкування, які є частиною (git workflow). Стратегія гілкування — це набір правил і домовленостей про те, як створювати гілки, називати їх і керувати ними в проєкті. У великому проєкті з багатьма розробниками гілок можуть бути сотні, і хороша стратегія допомагає тримати все під контролем. Ось кілька поширених підходів:
-
Centralized Workflow (централізований процес). Усі розробники працюють в одній гілці, зазвичай
main. Це найпростіший підхід, але він ускладнює паралельну роботу, бо всі змінюють ту саму гілку. Найчастіше його обирають команди, які звикли до старих централізованих систем контролю версій. -
Feature Branch Workflow (гілка на кожне завдання). Кожна нова функція розробляється у власній гілці, а після завершення зливається в
main. Це найпоширеніший підхід для команд, які працюють із Git. Він дає змогу розробляти кілька функцій одночасно, не заважаючи одне одному. -
Gitflow Workflow. Gitflow використовує довгоживучі гілки, як-от
mainіdevelop, плюс короткоживучі гілки для функцій, релізів і термінових виправлень (feature,releaseіhotfix). Такий підхід дає складним проєктам із багатьма релізами чіткий шлях від розробки до випуску. Але він доволі складний і для менших проєктів може бути надлишковим. -
Forking Workflow (робота через форки). Кожен розробник має власний (копію) репозиторію (англ. fork означає розвилку) і надсилає пулл реквести (англ. pull request означає запит на злиття змін) до основного репозиторію, де зміни переглядає і зливає той, хто має право запису. Такий підхід поширений у проєктах із відкритим кодом, де учасники не мають права запису до основного репозиторію. Вони працюють у власних копіях, а основний проєкт приймає лише перевірені зміни.
Універсальної стратегії гілкування не існує: найкращий підхід залежить від розміру та складності проєкту, кількості учасників і циклу релізів.
Тепер, коли зі стратегіями все зрозуміло, створімо нашу першу гілку для нової функції!
Проходь курс так, як він і задуманий: маленькими порціями, у сфокусованому лінійному порядку, поступово відкриваючи статті Gitopedia. Будь-коли можна продовжити зі справжнім Git у VS Code/Cursor/Antigravity/Windsurf.
але потрібен вхід