Git flow чи GitHub flow: яку модель гілок обрати

Ви

Банер розпродажу з'явився в понеділок о 8:00, хвилина в хвилину. А за обідом CEO спитав, чому в нас немає «нормальних релізів, як у всіх серйозних компаній».

Alex Tutor

Деякі серйозні компанії справді так працюють. Daniel, ти ж працював так до Котокорму?

Daniel

Три роки на фітнес-застосунку для телефонів. Нова версія кожні два тижні, і кожну перевіряли Apple і Google, перш ніж користувачі могли її завантажити. Ми працювали за git flow.

Alex Tutor

Git flow походить зі статті Вінсента Дріссена 2010 року «A successful Git branching model». Її головна ідея: дві гілки, що живуть завжди, main і develop, плюс три види тимчасових.

Alex Tutor

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

2c71a0eVersion 2.7.0v2.7.0
4d8e2b1Update translations
7a3f9c2Add reminder settings
c5e0d38Fix crash on loginhotfix/2.7.1
e8b2f14Merge hotfix/2.7.1v2.7.1
0f6c3a9Merge hotfix/2.7.1 into develop
91be4d7Send reminder notificationsfeature/workout-reminders
5b9d7e2Merge feature/workout-reminders
a4c1e86Bump version to 2.8.0
3e7f0b5Fix reminder text on small screensrelease/2.8.0
6d2a9f3Merge release/2.8.0mainv2.8.0
b8e4c71Merge release/2.8.0 into developdevelop

Ви

П'ять доріжок замість нашої однієї з короткими гілками. І мерджі в обидва боки.

Alex Tutor

Читай доріжку за доріжкою. У main лише випущені версії, і кожен коміт у ній отримує тег: v2.7.0, v2.7.1, v2.8.0. У develop збирають наступну версію. В оригінальній статті першу гілку називали master.

Daniel

Далі тимчасові. feature/* для кожної фічі, release/* для підготовки однієї версії, hotfix/* для термінового виправлення того, що вже є в користувачів.

І ми завжди мерджили через мердж-коміт, ніколи через squash, тож кожна фіча лишалася помітною в develop окремою петлею. Саме так радить оригінальна модель.

Alex Tutor

Питання 1

Зістав кожну гілку git flow з її роботою.

Торкніться відповіді, а потім рядка, до якого вона належить. Можна й перетягувати.

main
develop
feature/workout-reminders
release/2.8.0
hotfix/2.7.1

Відповіді, які ще треба розмістити

Ви

Тобто фічу мерджать у develop, а не в main. Користувачі її тоді отримують?

Daniel

Ні. Змерджено в develop означає «буде в наступній версії». Нагадування про тренування змерджили посеред спринту, а на телефони людей вони потрапили майже через два тижні.

Alex Tutor

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

Ви

Тобто в тій команді корисне питання «в якому це релізі?», а не «чи це змерджено?»

Daniel

Саме це питання навчився ставити наш маркетинг. Через «змерджено» вони анонсували речі, яких користувачі ще не бачили.

Alex Tutor

GitHub показує цю різницю, якщо читати уважно. У шапці pull request написано, що його змерджено «into develop» (у develop), а найновіший тег досі стара версія.

Alex Tutor

Питання 2

У git flow, щойно feature/workout-reminders змерджено в develop, користувачі, які оновлять застосунок, отримають нагадування про тренування.

День, коли змерджили нагадування

m1mainv2.7.1
d1
f1Add reminder settings
f2Send reminder notificationsfeature/workout-reminders
d2develop

ПравдаНеправда

Alex Tutor

Коли в develop набирається достатньо для наступної версії, від неї відрізають релізну гілку: release/2.8.0. З цієї миті це окрема доріжка.

Daniel

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

Alex Tutor

Тим часом develop лишається відкритою, тож нові фічі для 2.9.0 далі надходять. Коли реліз готовий, його мерджать у main, ставлять тег v2.8.0 і мерджать назад у develop, щоб його виправлення не загубилися.

Ви

А фіча, яку змерджили в develop через день після того, як відрізали реліз?

Daniel

Запізнилася на потяг. Чекає на 2.9.0. Тому дата відрізання була найважливішою датою в нашому календарі, і продакти щоспринту за неї боролися.

Alex Tutor

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

Ви

Звучить доволі передбачувано.

Daniel

Для календаря так. Ціна це очікування: навіть однорядкове виправлення в develop їде наступним потягом, якщо воно не настільки термінове, щоб робити хотфікс.

Alex Tutor

Питання 3

Які фічі отримають користувачі у версії 2.8.0?

Дві фічі й одна релізна гілка

m1v2.7.0
d1
x1Add dark themefeature/dark-mode
d2
y1Add daily step goalsfeature/step-goals
r1Bump version to 2.8.0
d3develop
r2Fix dark theme coloursrelease/2.8.0
m2mainv2.8.0

Оберіть одну відповідьТемна тема й цілі за кроками: обидві змерджено в develop до тегу v2.8.0Темна тема разом із виправленням кольорів; цілі за кроками чекають на наступний релізЛише цілі за кроками, бо їх змерджили останнімиЖодна, доки develop не змерджать у main

Ви

А якщо щось ламається в користувачів між релізами? Чекати два тижні?

Daniel

Не у випадку краху. Версія 2.7.0 падала під час входу в декого з користувачів. Ми відгалузили hotfix/2.7.1 прямо від main, від тегу v2.7.0, виправили лише це і випустили за два дні.

Alex Tutor

Хотфікс починається від того, що є в користувачів, а не від develop, де повно невипущеної роботи. Його мерджать у main з новим тегом v2.7.1 і в develop, щоб наступний реліз не повернув краш.

Daniel

Один нюанс: якщо в цей момент відкрита релізна гілка, виправлення йде в неї замість develop. У develop воно потрапить, коли реліз змерджать назад.

Ви

А чому важливо, щоб воно поверталося? Користувачі ж уже отримали виправлення.

Daniel

Бо 2.8.0 збирають із develop. Забудеш змерджити назад, і версія 2.8.0 знову падатиме під час входу. Я бачив таке один раз. Одного разу вистачило.

Alex Tutor

Питання 4

Розстав кроки хотфіксу для крашу під час входу у версії 2.7.0 по порядку.

Торкніться пункту, а потім місця, куди його поставити. Можна перетягувати або користуватися стрілками.

Alex Tutor

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

Ви

А для сайту, як у нас, де завжди працює лише одна версія?

Alex Tutor

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

З цим погодився й сам Дріссен. У 2020 році він додав до статті примітку: для вебзастосунків, які викладають безперервно, він радив простіший воркфлоу на кшталт GitHub flow, а git flow лишав для програм із явними версіями.

Daniel

Це збігається з моїм досвідом. Для застосунку він був саме те. Тут він би нас лише гальмував.

Ви

А як trunk-based виглядає в щоденній роботі?

Daniel

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

Alex Tutor

Питання 5

Якій команді git flow пасує найприродніше?

Оберіть одну відповідьМаркетинговий сайт, що викладає кожен мердж у main за кілька хвилинКоманда з двох людей, яка щодня виправляє друкарські помилки в документаціїІнтернет-магазин з однією живою версією і фіча-флагамиДесктопний застосунок із фіксованими щомісячними релізами, де клієнти досі користуються двома попередніми версіями

Alex Tutor

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

Alex Tutor

Гілки репозиторію фітнес-застосунку

develop
Default (основна) · оновлено сьогодні
main
Оновлено 9 днів тому · тег v2.8.0
release/2.9.0
Оновлено вчора · на 3 коміти попереду develop
feature/step-goals
Оновлено 2 години тому · pull request у develop
hotfix/2.8.1
Оновлено годину тому · pull request у main

develop поруч із main, плюс назви release/… і hotfix/…: це git flow. Часто develop навіть основна гілка репозиторію, тож нові pull requests за замовчуванням ідуть у неї.

Daniel

Лише main і кілька свіжих гілок fix/… чи feature/… з pull requests: це GitHub flow, як у нас. Майже нічого, крім main, гілки живуть години, багато флагів: trunk-based.

Ви

Тоді старий репозиторій Daniel це хрестоматійний приклад: develop як основна, релізна гілка й хотфікс одночасно.

А сторінка тегів покаже, чи вони взагалі нумерують версії.

Alex Tutor

Питання 6

Зістав список гілок кожного репозиторію з моделлю, яку там найімовірніше використовують.

Торкніться відповіді, а потім рядка, до якого вона належить. Можна й перетягувати.

main, develop (основна), release/3.2.0, hotfix/3.1.2, кілька feature/…
main, а також fix/cart-rounding і content/faq-refresh, кожна кількаденна, з pull request у main
Лише main і гілки віком кілька годин; незавершена робота схована за флагами

Відповіді, які ще треба розмістити

Alex Tutor

Тепер на хвилину уяви себе в старій команді Daniel, того тижня, коли змерджили нагадування. Маркетинг бачить у командному чаті «нагадування змерджено» і хоче анонсувати їх у п'ятницю.

Daniel

Релізну гілку відрізають наступного понеділка, потім тиждень тестування, потім перевірка в магазині, зазвичай день-два.

Ви

І навіть тоді користувачі мають оновити застосунок, щоб щось побачити.

Alex Tutor

Напиши відповідь для маркетингу. Два-три речення.

Alex Tutor

Питання 7Коротка відповідь · Завдання з перевіркою ШІ

Ти продакт у старій команді Daniel, що робить застосунок. feature/workout-reminders змерджили в develop у вівторок. release/2.8.0 відрізають наступного понеділка, тиждень тестують, потім надсилають у магазини (перевірка зазвичай триває день-два). Маркетинг питає: «Нагадування змерджено, можна анонсувати в цю п'ятницю?» Дай відповідь у 2–3 реченнях.

Напишіть відповідь і отримайте оцінку та відгук від нашого ШІ-рецензента.

Увійдіть, щоб отримати відгук ШІ

Ви

Повернімося до CEO. Він хоче відповідь, а не лекцію про доріжки.

Alex Tutor

Тоді з'ясуй, що його насправді турбує. «Нормальні релізи» зазвичай означає «хочу знати, що змінилося, і бути певним, що нічого не зламається».

Daniel

І те, і інше ми можемо мати без develop. Частина «що змінилося» буде на наступному уроці: теги й нотатки до релізів.

Alex Tutor

Напиши йому коротку рекомендацію. Спершу відповідь, потім аргументи.

Alex Tutor

Питання 8Кейс · Завдання з перевіркою ШІ

Напиши CEO коротку рекомендацію: чи варто Котокорму переходити на git flow?

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

Що відомо про Котокорм: один сайт, одна жива версія; GitHub flow з короткими гілками; кожен мердж у main викладають за кілька хвилин; main захищена (лише через pull requests, щонайменше одне схвалення, обов'язкові перевірки build і test, гілка має бути актуальною перед мерджем); кожен pull request отримує preview; фіча-флаги ховають незавершену роботу (осінній банер з'явився вчасно в понеділок). У березні невдалий мердж відкотили за десять хвилин. Зараз ніхто не може сказати, яка версія на сайті, і нотаток до релізів немає.

Напиши 6–10 рядків: твою рекомендацію, що змінив би git flow, коли він мав би сенс і як відповісти на справжнє занепокоєння CEO.

Напишіть відповідь і отримайте оцінку та відгук від нашого ШІ-рецензента.

Увійдіть, щоб отримати відгук ШІ

Ви

Отже, моя відповідь на «нормальні релізи»: так номерам версій і нотаткам до релізів, ні гілці develop.

Daniel

Цього тижня я поставлю наш перший тег. Бери каву й питання про те, що означає v1.4.0.

Alex Tutor

На цьому все. Ви відповіли на всі завдання — чудова робота.

Наступний урок: Релізи й версії: теги, SemVer, changelog