В моделі git-flow є дві головних гілки (master та develop), а також кілька додаткових. Розглянемо кожну з них окремо.
1. Master
Тут знаходиться стабільний робочий код, який готовий до розгортання на production-сервері. В даній гілці робота не ведеться і вона лише зливається з Release і Hotfix гілками. Master створюється автоматично при створенні репозиторію.
2.Develop
Тут знаходиться весь код, який готується до наступного релізу. Проте весь функціонал, який стосується наступних релізів, тут знаходитися не повинен.
3. Feature
Так називаються функціональні гілки, де знаходиться функціонал, наприклад, позадачно. Кожна функціональна гілка створюється окремо і після виконання завдання зливається лише з гілкою develop. Даний процес автоматизований і може бути виконаний однією командою:
git flow feature start test
Згідно вибраного шаблону іменування створиться гілка feature/test.
Після реалізації функціоналу потрібно злити цю гілку з develop. Це також можна зробити дуже просто:
git flow feature finish test
Вищенаведена команда зіллє гілку feature/test з develop і видалить її. Функціональні гілки, загалом, існують лише локально, але їх можна також додати і у віддалений репозиторій, якщо є необхідність, щоб над функціоналом працювало кілька людей одночасно. Це робиться за допомогою:
git flow feature publish test
Життєвий цикл функціональної гілки триває тільки під час реалізації задачі, після цього її можна видалити з віддаленого репозиторію стандартними git-інструментами.
4. Release
Після того, як готовий або майже готовий функціонал поміщено у гілку develop, можна починати готувати реліз. Це остання гілка перед зливанням в master. Тут можна зробити якісь мінімальні зміни у функціоналі або виконати багфікси. Додавати в цю гілку новий великий функціонал заборонено, а всі коміти потрібно переносити у гілку develop. Після створення гілки релізу v.1.0, в гілку develop вже можна зливати зміни, які будуть стосуватися наступного релізу (скажімо, це буде версія v.2.0).
Початок і закінчення роботи з гілкою релізу відбувається по аналогії з функціональними гілками:
git flow release start v.1.0.
git flow release finish v.1.0.
5. Hotfix
Якщо у master гілці з’явився баг, який потребує негайного втручання, то для цього є гілки hotfix. Команди для роботи з гілками виправлень також аналогічні:
git flow hotfix start
git flow hotfix finish
Дана гілка потрібна для того, щоб команда розробників мала змогу продовжувати роботу над функціоналом у гілці develop, в той час як один із програмістів виправляє баг у гілці hotfix. Після виправлення гілка зливається з master і develop. Хоча є один нюанс: якщо на момент виправлення гілка develop вже була стабільною та вже є гілка релізу, то зміни зливаються з release замість develop.
Git Flow - це модель, яка показує, як можна проводити розробку у команді, використовуючи можливості Git. Розробники можуть працювати над задачами як індивідуально, так і в групах, не заважаючи один одному. При цьому протягом всього життєвого циклу розробки існують лише дві основні гілки: master і develop, тому у репозиторії підтримується постійний порядок, оскільки всі інші гілки є лише тимчасовими. Дана модель є простою та зрозумілою, а застосування розширення автоматизації, яке було описано на початку статті, робить її дуже зручною у використанні.
