Git workflows

Робочий процес Git'а - це рецепт або рекомендація щодо того, як використовувати Git для послідовного та продуктивного виконання роботи. Робочі процеси Git'а заохочують розробників і DevOps-команди до ефективного і послідовного використання Git'а. Git пропонує велику гнучкість у тому, як користувачі керують змінами.

З огляду на те, що Git орієнтований на гнучкість, не існує стандартизованого процесу взаємодії з Git'ом. Працюючи з командою над проектом, керованим Git'ом, важливо переконатися, що всі члени команди згодні з тим, як буде застосовуватися потік змін. Щоб переконатися, що команда знаходиться на одній сторінці, слід розробити або вибрати узгоджений робочий процес Git'а. Існує кілька загальнодоступних робочих процесів Git'а, які можуть добре підійти вашій команді. Тут ми обговоримо деякі з них.

Під час читання пам'ятайте, що ці робочі процеси є радше рекомендаціями, ніж конкретними правилами. Ми хочемо показати вам, що можливо, щоб ви могли змішувати і поєднувати аспекти різних робочих процесів відповідно до ваших індивідуальних потреб.

Централізований

Централізований робочий процес - це чудовий робочий процес Git'а для команд, які переходять з SVN. Як і Subversion, Centralized Workflow використовує центральний репозиторій, який слугує єдиною точкою входу для всіх змін у проекті. Замість trunk, гілка розробки за замовчуванням називається main, і всі зміни фіксуються у цій гілці. Цей робочий процес не потребує жодних інших гілок, окрім основної.

Перехід на розподілену систему контролю версій може здатися складним завданням, але вам не потрібно змінювати існуючий робочий процес, щоб скористатися перевагами Git'у. Ваша команда може розробляти проекти точно так само, як вони це роблять за допомогою Subversion.

Однак, використання Git'а для керування робочим процесом розробки має кілька переваг над SVN. По-перше, це дає кожному розробнику власну локальну копію всього проекту. Це ізольоване середовище дозволяє кожному розробнику працювати незалежно від усіх інших змін у проекті - він може додавати коміти до свого локального сховища і повністю забути про попередні розробки, поки це не стане для нього зручним.

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

Feature branch

Основна ідея Feature branch¹ полягає в тому, що вся розробка функцій повинна відбуватися у виділеній гілці, а не в основній гілці. Така інкапсуляція дозволяє декільком розробникам легко працювати над певною функцією, не порушуючи основну кодову базу. Це також означає, що основна гілка ніколи не міститиме непрацюючого коду, що є величезною перевагою для середовищ безперервної інтеграції.

Інкапсуляція розробки функцій також дозволяє використовувати запити на pull/merge, які є способом ініціювати обговорення навколо гілки. Вони дають іншим розробникам можливість підписати функцію до того, як вона буде інтегрована в офіційний проект. Або, якщо ви застрягли на середині роботи над функцією, ви можете відкрити pull request і попросити колег внести свої пропозиції. Справа в тому, що за допомогою pull requests вашій команді неймовірно легко коментувати роботу один одного.

Робочий процес Git Feature Branch орієнтований на модель розгалуження, що означає, що він є керівним фреймворком для управління та створення гілок. Інші робочі процеси більше орієнтовані на репозиторій. Git Feature Branch Workflow може бути включений в інші робочі процеси. Робочі процеси Gitflow і Git Forking традиційно використовують Git Feature Branch Workflow для своїх моделей розгалужень.

Gitflow

Gitflow² - це альтернативна модель розгалуження Git'а, яка передбачає використання функціональних гілок і декількох первинних гілок. Вперше її опублікував і зробив популярною Вінсент Дріссен (Vincent Driessen) на nvie. У порівнянні з розробкою на основі trunk, Gitflow має численні, довговічніші гілки та більші коміти. За цією моделлю розробники створюють гілку фічі і відкладають її злиття з основною гілкою, поки фіча не буде завершена. Ці довгоживучі гілки вимагають більшої співпраці для злиття і мають вищий ризик відхилення від основної гілки.

Вони також можуть містити суперечливі оновлення.

Gitflow можна використовувати для проектів із запланованим циклом випуску та для найкращої практики безперервної доставки DevOps. Цей робочий процес не додає ніяких нових концепцій або команд, окрім тих, що необхідні для робочого процесу гілки функцій. Натомість, він призначає дуже конкретні ролі різним гілкам і визначає, як і коли вони повинні взаємодіяти. На додаток до функціональних гілок, він використовує окремі гілки для підготовки, супроводу та запису випусків. Звичайно, ви також можете використовувати всі переваги Feature Branch Workflow: pull requests, ізольовані експерименти і більш ефективну співпрацю.

¹ https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

² https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow