Git flow: гілки develop, release і hotfix

Git flow це модель гілок, зорієнтована на релізи, з 2010 року. Замість однієї main і коротких гілок у ній дві гілки, що живуть завжди, і три види тимчасових:

• main: лише випущені версії. Кожен коміт у ній отримує тег версії, як-от v2.7.0 чи v2.8.0. В оригінальному описі цю гілку називали master.
• develop: тут із готових фіч збирають наступну версію.
• feature/*: по одній фічі, відгалужується від develop і повертається в неї: git switch -c feature/workout-reminders develop.
• release/*: готує одну версію до випуску; лише виправлення й зміна номера версії.
• hotfix/*: термінове виправлення версії, яку користувачі вже мають; відгалужується від main.

Команди з git flow зазвичай зливають через мердж-коміт, а не squash (git merge --no-ff feature/workout-reminders), щоб кожна фіча лишалася видимою в develop як окрема петля. Так радить і оригінальна модель.

На графі це п'ять доріжок із мерджами в обидва боки, тоді як у GitHub flow одна доріжка й короткі бічні гілки.

У git flow фічу зливають у develop, а не в main. Для PM це головна відмінність: змерджено означає «буде в наступній версії», а не «користувачі вже мають».

Уяви develop як перон, а реліз як потяг, що відходить за розкладом. Нагадування про тренування змерджили посеред спринту, а на телефони людей вони потрапили майже через два тижні: треба було відгалузити релізну гілку, протестувати її, злити в main, поставити тег, пройти перевірку магазинів застосунків, а тоді кожен користувач мав оновити застосунок.

У GitHub flow Котокорму змерджено означає «на сайті за кілька хвилин». У git flow корисне питання не «чи змерджено?», а «у якому релізі?». Команди, які про це забувають, отримують маркетинг, що анонсує фічі, яких користувачі ще не бачать.

GitHub показує різницю, якщо читати уважно. Шапка pull request каже, що його змерджено «into develop», а найновіший тег у репозиторії досі попередня версія. git tag --contains <commit> нічого не виводить, доки не поставлять тег релізу, який містить цей коміт.

Коли команда працює в git flow, кожен статус-апдейт про фічу потребує двох фактів: у якій версії вона і коли ця версія дійде до користувачів. Саме слово «змерджено» найоманливіше, що можна надіслати маркетингу.

Добрий апдейт називає етап і наступну дату:

• «Нагадування в develop: вони вийдуть у 2.8.0. Релізну гілку відгалузять у понеділок, далі тиждень тестів і перевірка в магазинах; користувачі отримають їх приблизно за два тижні, після оновлення».
• «Цілі кроків не встигли до відгалуження 2.8.0; їх планують на 2.9.0».
• «2.8.0 схвалено в магазинах, і вона поступово розгортається».

Магазини застосунків додають власний етап: версію можуть схвалити, але розгортати поступово на дедалі більшу частку користувачів. І змін у мобільному застосунку ніхто не побачить, доки його не оновить.

Тож плануй анонси на день, коли версія справді доступна, а не на день мерджу фічі. Обіцяй дату лише після того, як реліз подано, і підтверджуй її ще раз, коли його схвалять.

Релізна гілка (release branch) це місце, де одна версія готується до випуску. Коли в develop набирається досить для наступної версії, її відгалужують: git switch -c release/2.8.0 develop. Відтоді це окрема доріжка.

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

Тим часом develop лишається відкритою, і фічі для 2.9.0 надходять далі. У релізній гілці їх немає: у 2.8.0 потрапляє лише те, що було в develop у мить відгалуження, плюс виправлення, зроблені в самій релізній гілці.

Коли реліз готовий, його зливають у main і ставлять тег (git tag -a v2.8.0 -m "Version 2.8.0"), а тоді зливають назад у develop, щоб виправлення, зроблені під час стабілізації, не загубилися.

Щоб відповісти «що є в 2.8.0?», знайди коміт, від якого відгалузили релізну гілку, і додай виправлення в ній. Порядок мерджів у develop не важить; важить момент відгалуження.

У git flow дата відгалуження, день, коли від develop створюють релізну гілку, найважливіша дата в календарі. Фіча, змерджена в develop наступного дня після відгалуження, спізнилася на потяг: її немає в релізній гілці, тож вона чекає на наступну версію.

Це дає плануванню чіткий ритм: дата відгалуження, тиждень стабілізації, дата релізу. Роадмапи в таких командах часто читаються за версіями: «2.8.0: нагадування, 2.9.0: цілі кроків». Для календаря це передбачувано, і PM часто завзято домовляються, що встигне до відгалуження.

Ціна це очікування. Навіть покращення в один рядок, змерджене в develop, їде наступним потягом, через два тижні чи місяць. Розклад обходить лише щось настільки термінове, що заслуговує на хотфікс.

Для PM звідси дві звички. Знай наступну дату відгалуження й заздалегідь скажи команді, які фічі мусять встигнути. А коли щось не встигло, скажи про це прямо й перенеси на наступну версію, а не проштовхуй фічу в релізну гілку, яка має приймати лише виправлення.

Хотфікс це термінове виправлення того, що користувачі вже мають, між релізами. Коли версія 2.7.0 у частини користувачів падає під час входу, ніхто не чекає два тижні на 2.8.0.

Хотфікс починається з того, що в користувачів, а не з develop, повної невипущеної роботи. У git flow це main на тезі релізу:

git switch -c hotfix/2.7.1 v2.7.0

Далі кроки:

1. Закомітити лише виправлення крашу й пройти рев'ю.
2. Злити хотфікс у main і поставити тег v2.7.1.
3. Злити хотфікс і в develop, щоб наступні релізи зберегли виправлення.
4. Випустити 2.7.1, для мобільного застосунку подати в магазини. Тег позначає саме те, що випускають, тож подання йде після тегу.

Нічого іншого в гілку хотфіксу не йде: жодних дрібних покращень «заодно». Що вужче виправлення, то швидше його протестувати й схвалити і то менший шанс зламати щось іще для користувачів, яким і так важко.

У хотфіксу два пункти призначення. Перший це main із новим тегом, щоб користувачі отримали виправлення. Другий це місце, де будують наступну версію, щоб вона зберегла виправлення.

Зазвичай це develop. Але якщо в цей момент відкрита релізна гілка, скажімо release/2.8.0, хотфікс іде в релізну гілку замість develop. А в develop виправлення потрапить, коли реліз зіллють назад. Якщо злити його лише в develop, воно оминуло б 2.8.0, яку відгалузили ще до виправлення.

Чому це важливо, хоча користувачі вже мають 2.7.1: версію 2.8.0 збирають із develop і її релізної гілки, а не з main. Забудеш злиття назад, і 2.8.0 вийде з тим самим крашем під час входу. Користувачі, які щойно отримали виправлення, втратять його з наступним оновленням, і ця регресія ніким не запланована.

Для PM після кожного хотфіксу варто одне питання: «чи є виправлення в наступному релізі?» Командою git branch --contains <commit> інженер перевірить, які гілки вже містять коміт із виправленням.

Git flow пасує, коли релізи це події:

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

Там релізні гілки дають стабільне місце для тестування однієї версії, а гілки хотфіксів лагодять саме ту версію, що в користувачів.

Для сайту з однією живою версією, як магазин Котокорму чи маркетинговий сайт, develop здебільшого додає очікування й подвійні мерджі. Багато вебкоманд перейшли на GitHub flow або на trunk-based development: усі зливають малі зміни в main щонайменше щодня, гілки живуть години, а не дні, а фіча-флаги ховають усе незавершене. Trunk-based вимагає дуже добрих автоматичних тестів і чималої дисципліни.

Пізніше навіть автор моделі додав примітку про те саме: вебзастосункам, які викладають безперервно, краще підходить простіший процес, а git flow для програм із явними версіями. Обирай за тим, як ви випускаєте, а не за тим, що звучить солідно.

Усі три моделі трапляться в інших репозиторіях: застосунок партнера, агенція, наступна робота. Сторінка гілок видає модель за секунди; у терміналі ті самі віддалені гілки показує git branch -r.

• Git flow: develop поруч із main, назви на кшталт release/3.2.0 і hotfix/3.1.2 і кілька гілок feature/…. Часто develop навіть основна гілка (default), тож нові pull requests автоматично йдуть у неї.
• GitHub flow: лише main і кілька свіжих гілок fix/…, feature/… чи content/…, кожна віком кілька днів і з pull request у main.
• Trunk-based development: майже нічого, крім main, гілки живуть години, а незавершену роботу ховають численні фіча-флаги.

Є ще дві підказки. Сторінка тегів показує, чи команда взагалі нумерує версії: рівний ряд v3.1.0, v3.1.1, v3.2.0 пасує до git flow. А список pull requests показує, у яку базову гілку йде більшість із них.

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