Які плюси і мінуси git-flow vs github-flow? [зачинено]

Нещодавно ми почали використовувати GitLab.

В даний час використовується "централізований" робочий процес.

Ми розглядаємо можливість переходу до потоку github, але хочу переконатися.

Які плюси і мінуси git-flow vs github-flow ?

Як обговорювалося в епізоді 17 GitMinutes, Ніколас Закас у своїй статті " Робочі процеси GitHub всередині компанії ":

Git-flow - це процес управління змінами в Git, який створив Вінсент Дріссен та супроводжувався деякими розширеннями Git для управління цим потоком.
Основна ідея мерзотника-потоку , щоб мати декілька окремих гілок , які завжди існують, кожен для іншої мети: master, develop, feature, release, і hotfix.
Процес розвитку функцій або помилок перетікає з однієї гілки в іншу, перш ніж її остаточно випустити.

Деякі респонденти вказали, що вони використовують git-flowзагалом.
Деякі почали з цього git-flowі віддалилися від нього.

Основною причиною відходу є те, що з цим git-flowпроцесом важко впоратися в моделі безперервного (або майже безперервного) розгортання.
Загальне відчуття полягає в тому, що git-flowдобре працює на продуктах у більш традиційній моделі випуску, де випуски проводяться раз на кілька тижнів, але цей процес значно руйнується, коли ви випускаєте раз на день або більше .

Коротко:

Почніть з максимально простої моделі (як правило, потік GitHub), і рухайтеся до більш складної моделі, якщо вам потрібно.

Ви можете побачити цікаву ілюстрацію простого робочого процесу, заснованого на GitHub-Flow за адресою:
" Проста модель розгалуження git ", основними елементами якої є:

1. master завжди має бути розгорнутим.
2. всі зміни, внесені через гілки функцій (pull-request + spage)
3. базування даних, щоб уникнути / вирішити конфлікти; злитися вmaster

Дійсний більш повний та надійний робочий процес див. У потоці gitworkflow (одне слово) .

Немає жодного срібного робочого процесу, за яким слід дотримуватися всіх, оскільки всі моделі є неоптимальними. Сказавши це, ви можете вибрати відповідну модель для свого програмного забезпечення на основі нижче наведених пунктів;

Кілька версій у виробництві - використовують Git-flow

Якщо ваш код має декілька версій у виробництві (тобто типові програмні продукти, такі як Операційні системи, Офісні пакети, Спеціальні програми тощо), ви можете використовувати git-flow. Основна причина полягає в тому, що вам потрібно постійно підтримувати попередні версії у виробництві, розробляючи наступну версію.

Єдина версія у виробництві простого програмного забезпечення - використовуйте Github-flow

Якщо ваш код постійно має лише одну версію у виробництві (наприклад, веб-сайти, веб-сервіси тощо), ви можете використовувати github-flow. Основна причина полягає в тому, що вам не потрібно робити складні речі для розробника. Як тільки розробник закінчить функцію або закінчить виправлення, її негайно пересувають у виробничу версію.

Єдина версія у виробництві, але дуже складне програмне забезпечення - використовуйте Gitlab-flow

Велике програмне забезпечення, наприклад Facebook та Gmail, можливо, вам знадобиться ввести гілки розгортання між вашою філією та головною гілкою, де можуть працювати інструменти CI / CD>, перш ніж вона надійде до виробництва. Ідея полягає у впровадженні більшого захисту у виробничій версії, оскільки її використовують мільйони людей.

Я використовую модель git-flow вже більше року, і це нормально.

Але це дійсно залежить від того, як буде розроблятися та розгортатися ваша програма.

Він добре працює, коли у вас є програма, яка має повільний потік розробки / розгортання.

Але, наприклад, як у GitHub у нас є додаток, який має швидкий потік розвитку / розгортання, ми розгортаємо щодня, а іноді і кілька разів на день, в цьому випадку git-flow має тенденцію сповільнювати все, на мою думку, і я використовую GitHub потік.

Інша річ, яку слід врахувати, це те, що git-flow - це не стандартний git, так що ви можете, і коли я скажу, що ви можете, я дійсно маю на увазі, ви знайдете розробників, які цього не знають, і тоді є крива навчання, більше шанс зіпсувати речі. Також, як згадувалося вище, хтось розробив набір сценаріїв, щоб полегшити використання git-потоку, тому вам не потрібно запам’ятовувати всі команди, це допоможе вам з командами, але запам’ятовування фактичного потоку - ваша робота. , Я не раз зустрічався, коли розробник не знав, чи це виправлення чи функція, або навіть найгірше, коли вони не можуть запам'ятати потік і наповнювати речі.

Існує щонайменше один графічний інтерфейс, який підтримує git-flow для Mac та Windows SourceTree .

У наші дні я більше схиляюся до потоку GitHub, завдяки своїй простоті та легкості в управлінні. Крім того, через "раннє розгортання часто" ...

Сподіваюся, це допомагає