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

Шість моделей на одному екрані — і питання, що обирають

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

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

1. 1.Скільки версій живе одночасно?

   1. 1.1Одна — модель 1 або 3; релізні гілки лише додали б cherry-pick
   2. 1.2Дві, недовго, поки триває викочування, — модель 2
   3. 1.3Кілька, місяцями, і кожну патчать, — модель 2 або 5, і спершу порахуйте ціну беквпортів

2. 2.Чи можна задеплоїти `main` будь-якої миті?

   1. 2.1Так: тести йдуть хвилини, і їм вірять, — модель 1 вам доступна
   2. 2.2Ні — виправте тести, перш ніж міняти модель; довша гілка ховає ненадійний main, а не лікує його

3. 3.Скільки pull request чекає на перше рев’ю?

   1. 3.1Години — гілки можуть бути короткими в будь-якій моделі
   2. 3.2День або більше — гілки будуть довгими в кожній моделі, хоч би що казала її схема

4. 4.Чи мають середовища відставати одне від одного?

   1. 4.1Ні — деплойте з main
   2. 4.2Так — просувайте одну протестовану збірку крізь середовища; гілка на середовище, модель 4, — запасний варіант, коли збірку неможливо просунути

5. 5.Чи затверджує реліз хтось поза командою — рев’ю в сторі, сертифікація?

   1. 5.1Ні — релізьте з main або з тегу
   2. 5.2Так — відгалужуйте релізну гілку в момент затвердження, а кожне виправлення робіть спершу в main

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

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

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

Джез Гамбл перетворив це на тест із трьох питань, який Мартін Фаулер опублікував у січні 2017 року. Чи кожен член команди щонайменше раз на день пушить у спільну головну гілку? Чи кожен такий коміт запускає автоматичну збірку й тести? Коли збірка ламається, чи зазвичай вона знову зелена за десять хвилин? Команда, що відповідає «ні» на перше, не практикує безперервну інтеграцію, хоч як називається її пайплайн.

Дослідження DORADORADevOps Research and Assessment — дослідження поставки софтуДослідницька програма, яку тепер веде Google Cloud: з 2014 року вона щороку опитує команди розробки й дає галузі стандартні метрики поставки — час поставки, частоту деплоїв, час відновлення, частку невдалих змін, а з 2024 року ще й частку переробок. Її головний висновок — швидкість і стабільність ідуть разом; її рівні — це відповіді одного року опитування, а не цілі.Докладніше в статті →Усі терміни 2016 і 2017 років дали цьому числа. Команди з вищими показниками поставки мали три чи менше активних гілок у репозиторії застосунку, зливали гілки в транк щонайменше раз на день і не мали ні заморозок коду, ні окремих фаз інтеграції. Перешкоди, які називає DORA, — ті самі, до яких повертається ця сторінка: рев’ю, що потребує кількох затверджень, асинхронне рев’ю, через яке гілки чекають, і тести, які не запускають перед комітом.

Звідки взялася кожна модель — і що її автори сказали згодом

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

Linux, 2005 і 2008 — багато гілок, що зливаються щодня

Лінус Торвальдс написав Git у квітні 2005 року для ядра Linux, і процес ядра — найстаріша модель тут. Кожна підсистема має мейнтейнера з власним деревом. Цикл релізу відкривається вікном злиття (merge window) приблизно на два тижні, протягом якого Торвальдс затягує дерева мейнтейнерів у головну гілку. Після нього приймають лише виправлення. Кандидати в реліз виходять приблизно щотижня, зазвичай до -rc6–-rc9, а нове ядро виходить кожні два-три місяці з приблизно 13 000 наборів змін.

Дерева, що живуть місяцями, самі по собі були б пеклом інтеграції. Запобігає цьому linux-next, який Стівен Ротвелл запустив у лютому 2008 року. Щоробочого дня він зливає всі дерева підсистем разом, збирає результат і публікує його, тож конфлікти між деревами спливають за тижні до вікна злиття. Урок той самий, до якого раз у раз повертається ця сторінка: важить не те, скільки існує гілок, а те, як часто вони зустрічаються.

GitFlow, 2010 — і примітка автора 2020 року

Вінсент Дріссен опублікував «A successful Git branching model» 5 січня 2010 року. У моделі дві постійні гілки: main (тоді master), що завжди відображає production, і develop, куди інтегрують завершену роботу. Фіче-гілки відходять від develop і повертаються в неї. Релізна гілка відходить від develop, поки готують реліз, і зливається і в main, і в develop. Hotfix-гілка відходить від main і зливається в обидві — або в релізну гілку, якщо та на цей момент існує. Кожне злиття робиться з --no-ff, тож кожна фіча лишається видимою як група комітів.

5 березня 2020 року Дріссен додав на початок допису примітку-рефлексію. Коротко: модель писали для софту з явними версіями, вебзастосунки з безперервною поставкою стали звичним випадком, і для них він радив би простіший процес, як-от GitHub Flow. Модель ніколи не була хибною. Вона відповідала на питання команди, що випускає версію 2.4, підтримуючи 2.3, — а більшість команд, які її взяли, такого питання не мали.

GitHub Flow, 2011 — а потім деплой до злиття

Скотт Чейкон описав власний процес GitHub 31 серпня 2011 року — як реакцію на те, що GitFlow завеликий для більшості команд. У ньому шість правил. Усе в main придатне до деплою. Нова робота йде в гілку від main з описовою назвою. Регулярно пушіть цю гілку на сервер. Відкривайте pull request, коли потрібен відгук або робота здається готовою. Зливайте лише після того, як хтось переглянув зміну. Деплойте одразу після злиття. Тоді GitHub деплоїв близько двох десятків разів за звичайний день.

До 2015 року GitHub поміняв два останні правила для власного сайту. Аман Гупта описав це в червні 2015-го: новий код деплоять із гілки pull request, а зливають лише після того, як його підтверджено в production. Якщо деплой гілки пішов погано, відкат — знову задеплоїти main, який завжди справний, бо нічого неперевіреного туди не потрапляє. Документація Microsoft називає ціну: кожен pull request чекає в черзі на деплой, і вона стає вузьким місцем, щойно на день припадають сотні pull request.

GitLab Flow, 2014 — і вихід із документації 2023 року

Сітсе Сейбранді, співзасновник GitLab, запропонував GitLab Flow 29 вересня 2014 року для команд, яким GitHub Flow не пасує, бо деплой — це не злиття. Модель додає гілки нижче за течією: по одній на середовище, як-от stagingstagingсередовище-репетиціяКопія продакшену, на якій зміни пробують до того, як їх зустрінуть справжні користувачі. Скільки вона доводить, повністю залежить від того, наскільки вона схожа на продакшен: staging із десятою частиною даних, без реального трафіку й з іншою конфігурацією показує, що код запускається, і майже нічого більше.Усі терміни і production, або на кожну підтримувану версію. Коміти течуть лише вниз, тож кожен рядок тестують у кожному середовищі, перш ніж він дійде до наступного. Для виправлень модель формулює правило, яке радить і ця сторінка; GitLab назвав його «upstream first» і послався на Google і Red Hat: злийте в main, потім зробіть cherry-pick у релізну гілку.

2023 року GitLab вилучив сторінку GitLab Flow зі своєї документації продукту: у версії 16.0 вона стала загальним вступом до Git-процесів, а з 16.4 перенаправляє на допис у блозі. Ідея живе, але гілки середовищ мають слабкість, на якій оригінал не зупинявся. Збірка, яку деплоять у production, — не та, яку тестували на staging, а свіжа збірка злиття. Тому питання 4.2 віддає перевагу просуванню однієї протестованої збірки із середовища в середовище на одній гілці.

Google, 2016 — один транк на 25 000 інженерів

У липні 2016 року Рейчел Потвін і Джош Левенберг описали репозиторій Google у Communications of the ACM: один репозиторій на приблизно два мільярди рядків коду й 35 мільйонів комітів, яким користуються понад 25 000 інженерів. Розробка в гілках там незвична й погано підтримана. Новий і старий шляхи коду живуть поруч за умовними прапорцями. Релізи відгалужують від обраної ревізії, а виправлення роблять у головній гілці й потім переносять у релізну через cherry-pick. Це найсильніший доказ, що trunk-based development масштабується: інструменти довелося будувати під нього, але модель гілкування з розміром не змінилася.

Microsoft, 2018 — Release Flow

Едвард Томсон описав модель команди Azure DevOps у квітні 2018 року й назвав її Release Flow. Розробники працюють у коротких тематичних гілках, які зливають у main через pull request, і найзавантаженіші репозиторії приймають понад 200 pull request на день. main ніколи не деплоять напряму. Наприкінці кожного тритижневого спринту відгалужують релізну гілку — на спринті 129 це releases/M129, — і деплоять саме її. Релізні гілки ніколи не зливають назад у main.

Hotfix завжди починається в main, а потім його переносять у релізну гілку через cherry-pick просто зі сторінки pull request. Документація Microsoft пояснює причину реченням, яке варто повісити на стіну: виправити релізну гілку, не перенісши зміну в main, означає, що баг повернеться з наступним деплоєм, а про main легко забути в стресі аварії. Під час викочування кільце за кільцем у production одночасно дві релізні гілки, тож виправлення в цей період іде в обидві.

Релізні гілки — і в який бік рухається виправлення

Релізна гілка існує з однієї причини: дати main рухатися далі, поки одну версію стабілізують, випускають і патчать. Усе інше в ній випливає з одного рішення — де виправлення роблять спершу. Дві відповіді дають дуже різні збої.

Upstream first має один чесний виняток. Іноді баг неможливо відтворити в main, бо код там уже змінився. Тоді виправлення роблять у релізній гілці й записують, чому воно не дійшло до main, — бо main воно не потрібне. Усе інше йде спершу в main.

Ціна підтримуваних версій

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

Ось чому проєкти, що підтримують кілька версій, публікують, скільки саме і як довго. Node.js, Java і ядро Linux називають свої лінії LTSLTSLong-Term Support — реліз, що роками отримує патчіЛінія релізів, що й далі отримує виправлення безпеки та критичних багів упродовж оголошеного строку після виходу новіших версій, але без нових можливостей. Вона дає команді оновлюватися у власному темпі — до кінцевої дати в таблиці підтримки, після якої наступна вразливість не матиме виправлення взагалі.Усі терміни і дати їхнього завершення. Команда з трьома клієнтами на трьох версіях має ту саму проблему без політики — і зазвичай дізнається про це під час інциденту.

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

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

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

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

Найкращі опубліковані дані про те, як виглядає швидке рев’ю, — від Google. Його дослідження 2018 року на приблизно дев’яти мільйонах переглянутих змін показало медіанне очікування першого відгуку менше години для малих змін і близько п’яти годин для дуже великих, а для всього рев’ю — медіану менше чотирьох годин. Менше чверті рев’ю мали більше ніж одного затверджувача. Швидкість і розмір — це один висновок, а не два.

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

Незавершена робота за прапорцем

Гілка часто лишається відкритою просто тому, що фіча не дороблена, а половини фічі в main ніхто не хоче. Відповідь — feature flagfeature flagперемикач навколо нового кодуПеремикач, що під час роботи вирішує, чи активний шматок коду, — тож код може потрапити в продакшен вимкненим і бути ввімкненим для обраної аудиторії пізніше. Він відділяє деплой від релізу й має ціну: кожен живий прапорець — це розгалуження в коді, яке має працювати в обох станах.Докладніше в статті →Усі терміни: код зливають щодня, і він лишається вимкненим, доки не буде завершений. Ціна — сам прапорець, який треба прибрати, щойно фічу повністю ввімкнено; сторінка про планування релізу описує чотири види прапорців і скільки має жити кожен.

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

Звичне заперечення проти коротких гілок — великий рефакторинг: заміна платіжного провайдера, зміна ORMORMObject-Relational Mapping — обʼєкти замість SQLБібліотека, що підставляє обʼєкти мови там, де в базі лежать рядки таблиці, — тож SQL ви майже не пишете. Зручність коштує контролю: згенерований запит буває значно важчим за той, який ви написали б самі, і зʼясовується це вже під навантаженням.Докладніше в статті →Усі терміни, перебудова модуля. Відповідь на нього — branch by abstraction; назву техніці дав Пол Геммант у квітні 2007 року. Поставте інтерфейс перед тим, що замінюєте. Переводьте на нього викликачів, по одному злиттю за раз. Збудуйте за ним нову реалізацію, перемкніться, потім видаліть стару. Кожен крок — мала зміна, яку можна злити окремо, і кодову базу можна випустити на будь-якому з них.

Як тримати main зеленим, коли зливають багато людей

Короткі гілки породжують нову проблему. Два pull request можуть кожен пройти свої перевірки й однаково разом зламати main, бо жоден не тестували з іншим. Ґрейдон Гоар, творець Rust, назвав відповідь «правилом не ракетної науки»: автоматично тримати репозиторій коду, що завжди проходить усі свої тести, — перевіряючи кожну зміну злитою з поточним main, перш ніж вона туди потрапить. Саме це робить merge queue. У GitHub черга злиття стала загальнодоступною в липні 2023 року, а в GitLab те саме зветься merge trains.

Merge, rebase чи squash

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

Жоден із трьох помітно не впливає на результати поставки: оберіть один, запишіть і припиніть обговорення. Одну практичну різницю варто знати. git bisect знаходить коміт, що щось зламав, ділячи історію навпіл, і працює найкраще, коли кожен коміт у main збирається й проходить тести. Squash і merge queue обидва це гарантують. Rebase двадцяти проміжних комітів — ні.

Що справді важить — правило, з яким погоджуються без суперечок: ніколи не переписуйте історію гілки, на якій хтось інший уже збудував свою роботу. Переписати власну гілку до рев’ю — нормально. Якщо після цього доводиться робити force-push, використовуйте git push --force-with-lease: він відмовить, якщо тим часом хтось інший запушив. Переписування спільної гілки ламає всіх, хто на ній будував, і, на відміну від естетичного питання, це не справа смаку.

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

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

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

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

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

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

• МенеджментПланування релізуПланування релізу — це рішення про те, що потрапляє до користувачів, коли і як ви дізнаєтесь, що щось пішло не так. Найкорисніший крок у ньому — перестати вважати деплой і реліз однією подією: код потрапляє в production вимкненим, а відкриття доступу стає окремим, зворотним рішенням, яке ухвалюють поетапно. Сторінка починається з готового плану одного релізу; далі — деплой проти релізу, фіксована дата проти фіксованого обсягу, стратегії викочування, чотири види feature flag, шлях назад, чотири релізи, що провалилися, і рядок, якого бракувало кожному, та як вимірювати процес.
• МенеджментChangelogChangelog — це впорядкований, зрозумілий людині перелік помітних змін у кожній версії програми, написаний для того, хто вирішує, чи оновлюватися. Саме через цього читача вивантаження повідомлень комітів, хай яке повне, changelog не є. Сторінка починається з готового changelog; далі — документи, які з ним плутають, що обіцяє номер версії, як написати запис, депрекація, як далеко чесно заходить автоматизація, чотири релізи, де проблемою був рядок changelog, і де практика вироджується.
• ІнфраструктураCI/CDБезперервна інтеграція — це не сервер, що ганяє ваші тести, а звичка зливатися в одну спільну гілку достатньо часто, щоб конфлікти лишалися малими; автоматизація існує, щоб зробити цю звичку безпечною. Безперервна доставка — друга половина: один артефакт, зібраний один раз і просунутий середовищами без перезбирання. На цій сторінці — як упорядкувати етапи, чому нестабільний тест руйнує авторитет конвеєра, чим насправді торгують стратегії розгортання і які чотири числа кажуть, чи все це працює.