Git flow
Модель галуження git-flow
— це п’ять правил і купа бухгалтерії. Правила прості; саме на бухгалтерії люди
помиляються о шостій вечора в день релізу — вливають хотфікс у main і забувають
про develop або вішають тег не на ту гілку.
⌘K → Git flow веде цю бухгалтерію за вас.
Схема
| Гілка | Що містить |
|---|---|
Гілка релізів (main) |
Те, що працює у продакшені. Кожен реліз тегується тут. |
Гілка інтеграції (develop) |
Місце, де накопичується завершена робота між релізами. |
feature/* |
Одна одиниця роботи, відгалужена від develop. |
release/* |
Версія, яку стабілізують, відгалужена від develop. |
hotfix/* |
Термінове виправлення, відгалужене від main — продакшен не може чекати на develop. |
Gitcito читає й записує ті самі ключі конфігурації gitflow.*, якими користується
CLI git flow (gitflow.branch.master, gitflow.prefix.feature, …).
Репозиторій, на якому хтось уже виконав git flow init, розпізнається одразу, а
репозиторій, налаштований тут, потім працює з CLI. Gitcito усюди виконує звичайні
команди git — сам CLI встановлювати не потрібно.
Налаштувати записує ці ключі і, якщо гілки інтеграції ще немає, створює її з гілки релізів. Більше нічого не чіпається. Будь-яку назву чи префікс можна змінити згодом через Редагувати схему.
Початок
Оберіть тип, введіть назву, натисніть Почати. Діалог показує, яку гілку він збирається створити і від якої гілки, ще до того, як ви на це погодитеся:
feature/search from develop
hotfix/1.0.1 from main
Назва — те, що ви вводите; префікс береться зі схеми.
Завершення
Завершити — саме та частина, яку варто автоматизувати, бо це кілька кроків, і всі вони мають відбутися:
| Тип | Що робить Gitcito |
|---|---|
| Feature | Вливає в develop із --no-ff, видаляє гілку, залишає вас на develop |
| Release | Вливає в main, вішає тег, вливає в develop, видаляє гілку, залишає вас на develop |
| Hotfix | Вливає в main, вішає тег, вливає в develop, видаляє гілку, залишає вас на main |
--no-ff тут навмисно: саме коміт злиття робить гілку видимою у
графі згодом. Без нього коротка фіча розчиняється у прямій лінії, і
модель втрачає те, заради чого існувала.
Тег має вигляд <префікс тегів версій><назва> — release/1.1.0 з типовим
префіксом стає v1.1.0. Зніміть галочку Тегувати реліз, щоб пропустити це,
і напишіть повідомлення тега, якщо хочете більшого за типове.
Чого воно робити відмовляється
- Брудне робоче дерево його зупиняє. Спершу закомітьте або зробіть стеш; завершення зливає дві гілки й двічі рухає HEAD, і робити це навколо незакоміченої роботи — найкоротший шлях її втратити.
- Конфліктне злиття відкочує все назад. Якщо злиття в main пройшло, а злиття в develop дало конфлікт, ви б інакше лишилися з наполовину завершеним релізом. Gitcito повертає кожну гілку туди, де вона була, і повідомляє про конфлікт. Влийте цю гілку вручну, розберіться з нею в резолвері конфліктів — і далі флоу ваш, завершуйте руками.
- Воно ніколи не пушить. Завершення локальне. Відправте main, develop і новий тег, коли будете готові, — дивіться синхронізацію.
Скасування
Одне Скасувати повертає все назад: обидві гілки повертаються на попередні коміти, тег видаляється, а завершена гілка відтворюється на своїй старій верхівці. Саме тому завершення безпечно спробувати.
Коли цим не варто користуватися
Git flow пасує до програм із версійованими релізами та підтримуваною продакшен-
гілкою. Якщо ви деплоїте з main кілька разів на день, гілки релізів і хотфіксів
— це церемонія, якою ви не скористаєтеся; сюди краще пасують
стековані гілки або звичайні короткоживучі гілки від main.
Фічева половина моделі й сама по собі працює чудово.