Категорії

Git flow - модель роботи з репозиторієм

13.03.2014
Автор:

В даній статті ми розглянемо модель роботи з гілками Git під назвою git-flow. Модель була запропонована Вінсентом Дріссеном у його статті “A successful Git branching model” і використовується в різних варіаціях. Загальна схема моделі виглядає наступним чином:

Розглянемо схему детальніше.

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

apt-get install git-flow

У своїх прикладах ми будемо використовувати цей набір.

Для початку, веб розробнику потрібно створити порожній репозиторій. Це можна зробити за допомогою команди:

git flow init

Після цього користувачу пропонується вибрати шаблони для іменування гілок:

No branches exist yet. Base branches must be created now
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []

Тут можна сміливо використовувати значення по замовчуванню та просто пройти всі пункти, натискаючи Enter. У випадку, якщо не потрібно нічого змінювати, можна використати команду:

git flow init -d

В моделі 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, тому у репозиторії підтримується постійний порядок, оскільки всі інші гілки є лише тимчасовими. Дана модель є простою та зрозумілою, а застосування розширення автоматизації, яке було описано на початку статті, робить її дуже зручною у використанні.

Голосів: 1 Рейтинг: 5

Також по темі

1

Продовжуючи розгляд можливостей модуля Panels, в цьому блозі мова піде про створення власного контексту за допомогою Chaos tool suite.

2

При розробці збірки CommerceBox у нас виникло питання, як зберігати у фічі певний функціонал для apps. Метод Feature Injection вирішує цю проблему.  

3

Apps -  це модуль, що позиціонується як наступний крок у розвитку...

4

В даній статті мова піде про можливість встановлення ядра Drupal 8 як сабмодуля. Ми не розважатимемо за саме поняття сабмодулів, ні за їх недоліки чи переваги, а лише зобразимо в деталях, спосіб у...

5

Вигляд форми авторизації/реєстрації тепер можна змінити через інтерфейс адміністратора за допомогою нашого модуля Customize login form.

Давайте обговоримо ваш проект у всіх деталях

Шукаєте хороших Drupal-розробників? А ми тут! Яким би ви хотіли бачити проект своєї мрії? Зв’яжіться з нами і розкажіть про це. Із задоволенням втілимо вашу мрію в життя!

Приєднуйтесь до людей, які вже підписалися!

Хочете бути в курсі важливих і цікавих речей, що відбуваються? Ми інформуватимемо Вас про розвиток та нові події в Drupal, дизайні, тестуванні та ін.

Відпишіться у будь-який час