Гіт став де-факто промисловим стандартом системи контролю версій у створенні програмного забезпечення. Про те, що таке гіт і як почати, спочатку почитайте мою статтю про це. Прочитали? Чудово, поїхали далі! Подобається нам чи ні, але інструмент, який Лінус Товальдс створив, не має наміру йти на пенсію. Тому є сенс поговорити про те, як працювати розподіленим командам у гіті та яку стратегію розгалуження для цього вибрати. І це питання зовсім не пусте. Часто в ситуації, коли збирають нову команду розробників, котрі не співпрацювали один з одним, стратегія розгалуження — це одне з перших, що потрібно вирішити. І будуть люди, які з піною біля рота доводитимуть, що одна стратегія краща за іншу. Тому я хочу донести до вас інформацію про те, якими вони взагалі бувають.
А чи потрібні стратегії розгалуження?
А ось потрібні, та ще й як потрібні. Бо якщо не домовитися про щось у команді, вийде, що кожен робитиме, що хоче:
працювати у тій гілці, у якій хоче;
смерджувати в інші гілки, які він хоче;
видаляти якісь гілки;
створювати нові;
і так - кожен із членів команди в некерованому потоці.
Тому нижче наведу три стратегії. Поїхали!
GitHub Flow стратегія
Стратегія розгалуження, як би це не було дивно, віддається перевага GitHub :) До неї додається набір правил , яким потрібно слідувати:
Код у master гілці має бути не поламаним і готовим до розгортання у будь-який час (тобто не можна туди покласти код, який завадить зібрати проект і розгорнути його на сервері).
Коли планується робота над новою функціональністю, необхідно створити нову гілку (feature гілку) на основі master гілки та дати їй зрозуміле ім'я. Комітувати свій код локально та регулярно пушити свої зміни на цю ж гілку у віддалений репозиторій.
Відкрити Pull-Request (що таке pull-request, можна почитати тут ), коли є чітке відчуття, що робота готова і може бути смержена в master гілку (або якщо впевненості немає, але хочеться отримати відгуки про виконану роботу).
Після того, як нову фічу в пул-реквесті запругли, її можна смердити в master гілку.
Коли зміни смерджені в master гілку, їх потрібно розгорнути на сервері негайно.
По GitHub Flow виходить, що перш ніж почати роботу над чимось новим, чи це виправлення або нова фіча, потрібно створити нову гілку на основі master'а і дати їй відповідне ім'я. Далі починається робота над реалізацією. Потрібно постійно відправляти коміти на віддалений сервер з тим самим ім'ям. Коли приходить розуміння, що все готове, потрібно створити пул-реквест у master гілку. Потім хоча б один, а краще дві людини повинні подивитися цей код і натиснути Approve. Зазвичай обов'язково має подивитись тимлід проекту і хтось ще, і тоді вже можна завершувати пул-реквест. GitHub Flow ще відомий тим, що драйвіт Continuous Delivery (CD) на проекті. Тому що коли зміни заходять у master гілку, вони повинні одразу ж бути розгорнуті на сервері.
GitFlow стратегія
Попередня стратегія (GitHub Flow) була, по суті, не дуже складною. Є два типи гілок: master і фіче гілки. А ось GitFlow вже серйозніше. Як мінімум з картинки вище ви можете зрозуміти) Отже, як працює ця стратегія? Загалом GitFlow складається з двох постійних гілок і кількох типів тимчасових гілок (У контексті GitHub Flow, master гілка – постійна, а інші – тимчасові). Постійні гілки:
master: цю гілку просто так ніхто не повинен чіпати/нічого не пушити туди. У цій стратегії master відображає останню стабільну версію, яку використовують у продакшені (тобто реальному сервері);
development – це гілка для розробки. Потенційно може бути нестабільна.
Розробка ведеться за допомогою трьох допоміжних тимчасових гілок :
Фіче гілки (feature branches) – для розробки нової функціональності.
Релізні гілки (release branches) для підготовки випуску нової версії проекту.
Хотфікс гілки (hotfix branches) - швидке рішення дефекту, який знайшли реальні користувачі на реальному сервері.
Фіче гілки (feature branches)
Фіче гілки створюються розробниками нового функціоналу. Вони завжди повинні створюватися на основі розвитку гілки. Після завершення роботи над новою функціональністю, потрібно створити пул-реквест у розвитку гілку. Зрозуміло, що у великих командах одночасно може бути більше однієї фічі гілки. Ще раз зверніть увагу на картинку на початку опису стратегії GitFlow.
Релізні гілки (release branches)
Коли необхідна кількість нових фіч підготовлена в розробці гілці, можна підготуватися до випуску нової версії продукту. У цьому нам допоможе релізна гілка. яка створюється на основі розвитку гілки. У ході роботи з релізною гілкою потрібно знайти і полагодити всі дефекти. Всі нові зміни, які потрібні для стабілізації релізної гілки, потрібно також смердити назад у розробці. Робиться це для того, щоб стабілізувати та розвиток гілку. Коли тестувальники скажуть, що гілка досить стабільна для нового релізу, її смерджують у master гілку. Далі на цьому коміті створюється мітка (tag: докладніше можна прочитати тут ), якій присвоюється номер версії. Як приклад можна подивитися на картинку на початку стратегії. Так ось, там Tag 1.0 — це мітка, яка вказує на версію 1.0 проекту. І останнє - це хотфікс гілки.
Хотфікс гілки (Hotfix branches)
Хотфікс гілки також призначені для релізу нової версії в master. Тільки різниця у тому, що цей реліз не планується. Бувають ситуації, коли дефекти сягають релізу і вже виявляються у роботі. Наприклад, iOS: як тільки випустять нову версію, так одразу тобі купа оновлень із фіксами дефектів, які виявляються після релізу. У зв'язку із цим потрібно швидко пофіксувати цей дефект та випустити нову версію. На нашому малюнку це відповідає версії 1.0.1. Ідея полягає в тому, що робота над новими функціональностями може не зупинятися в моменти, коли потрібно полагодити дефект на реальному сервері (як у нас кажуть, на проді: знову калька з англійського production). Хотфікс гілка повинна створюватися від master гілки, тому що вона відображає стан, який працює в проді. Як тільки рішення дефекту готове, смерджується в master, створюється нова мітка. Так само, як і підготовка релізної гілки, хотфікс гілка повинна смердити своє рішення в розробці гілки.
The Forking Workflow стратегія
У рамках Forking Workflow стратегії розробка ведеться так, що є два репозиторії:
Оригінальний репозиторій, до якого смерджуватимуться всі зміни.
Форк репозиторій (це копія оригінального репозиторію у володінні іншого розробника, який хоче внести зміни до оригінального).
Поки що звучить якось дивно, так? Тим, хто вже стикався з open-source розробкою, цей підхід уже знайомий. Така стратегія дає таку перевагу: розробка може вестись у форк-репозиторії та без надання прав на спільну розробку в оригінальному. Вочевидь, що власник оригінального репозиторію вправі відхаботи запропоновані зміни. Або погодитись і смердити їх. Це зручно і власнику оригінального репозиторію, і розробнику, який хоче взяти участь у створенні продукту. Наприклад, можна запропонувати зміни в ядро лінуксу . Якщо Лінус вирішить, що вони мають сенс, зміни буде додано (!!!).
Приклад The Forking Workflow
The Forking Flow застосовується на GitHub'e в момент, коли є бібліотека, яку хочеться використовувати. У ній є дефект, який заважає використати її повноцінно. Припустимо, ви занурабося досить у проблему та знаєте рішення. За допомогою The Forking Workflow стратегії можна вирішити це завдання без надання прав на роботу в оригінальному репозиторії бібліотеки. Щоб почати роботу, потрібно вибрати якийсь репозиторій, наприклад, ядро Spring Framework , знаходимо у верхньому правому кутку кнопку Fork і натискаємо її: Це займе деякий час, після чого з'явиться копія цього оригінального репозиторію в особистому обліковому записі, в якому буде вказано, що вона є форком: Далі ви можете працювати з цим репозиторієм у звичайному режимі, додавати зміни в master гілку і коли все буде готове створити Pull-Request в оригінальний репозиторій. Для цього потрібно натиснути кнопку New Pull request :
Яку стратегію вибрати
Гіт – це гнучкий та потужний інструмент, який дозволяє працювати, використовуючи широкий спектр процесів та стратегій. Але що більший вибір, то складніше вирішити, яку саме стратегію зараз обрати. Зрозуміло, що немає однозначної відповіді всім. Все залежить від ситуації. Тим не менш, є кілька рекомендацій, які можуть допомогти у цьому:
Спочатку краще вибирати найпростішу стратегію. Переходити до складніших стратегій лише тоді, коли це потрібно.
Розглядати стратегії, в яких якнайменше типів гілок для розробників.
Подивитися на плюси та мінуси різних стратегій та, відповідно до проекту, вибрати потрібну.
Це все, що я хотів розповісти з приводу стратегії розгалуження у гіті. Дякую за увагу :) Підписуйтесь на мій гітхаб аккаунт , я там часто викладаю свої напрацювання в різних технологіях та інструментах, які використовую в роботі
Подобається нам чи ні, але інструмент, який Лінус Товальдс створив, не має наміру йти на пенсію. Тому є сенс поговорити про те, як працювати розподіленим командам у гіті та яку стратегію розгалуження для цього вибрати. І це питання зовсім не пусте. Часто в ситуації, коли збирають нову команду розробників, котрі не співпрацювали один з одним, стратегія розгалуження — це одне з перших, що потрібно вирішити. І будуть люди, які з піною біля рота доводитимуть, що одна стратегія краща за іншу. Тому я хочу донести до вас інформацію про те, якими вони взагалі бувають.
Стратегія розгалуження, як би це не було дивно, віддається перевага GitHub :) До неї додається набір правил , яким потрібно слідувати:
Попередня стратегія (GitHub Flow) була, по суті, не дуже складною. Є два типи гілок: master і фіче гілки. А ось GitFlow вже серйозніше. Як мінімум з картинки вище ви можете зрозуміти) Отже, як працює ця стратегія? Загалом GitFlow складається з двох постійних гілок і кількох типів тимчасових гілок (У контексті GitHub Flow, master гілка – постійна, а інші – тимчасові). Постійні гілки:
У рамках Forking Workflow стратегії розробка ведеться так, що є два репозиторії:
Це займе деякий час, після чого з'явиться копія цього оригінального репозиторію в особистому обліковому записі, в якому буде вказано, що вона є форком: 
Далі ви можете працювати з цим репозиторієм у звичайному режимі, додавати зміни в master гілку і коли все буде готове створити Pull-Request в оригінальний репозиторій. Для цього потрібно натиснути кнопку New Pull request : 
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ