Каковы плюсы и минусы git-flow и github-flow? [закрыто]


125

Недавно мы начали использовать GitLab.

В настоящее время используется «централизованный» рабочий процесс.

Мы думаем о переходе на github-flow, но я хочу убедиться.

Каковы плюсы и минусы git-flow и github-flow ?

Ответы:


133

Как обсуждалось в эпизоде ​​17 GitMinutes, Николас Закас в своей статье « Рабочие процессы GitHub внутри компании »:

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

Некоторые респонденты указали, что употребляют git-flowв целом.
Некоторые начали с этого git-flowи отошли от него.

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

Коротко:

Начните с модели как можно более простой (например, GitHub flow) и переходите к более сложной модели, если вам нужно.


Вы можете увидеть интересную иллюстрацию простого рабочего процесса, основанного на GitHub-Flow по адресу:
« Простая модель ветвления git », с основными элементами:

  1. master всегда должен быть развернутым.
  2. все изменения, сделанные через ветки функций (запрос на вытягивание + слияние)
  3. переустановить, чтобы избежать / разрешить конфликты; слиться сmaster

https://a248.e.akamai.net/camo.github.com/9783623eba280ba5ace8b9e63842be52af2f0546/687474703a2f2f7374617469632e62656e65742e61692f736b697463682f666c6f772d32303133303932362d3139333431392e706e67


Для более полного и надежного рабочего процесса см. Gitworkflow (одно слово) .


88

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

Несколько версий в производстве - используйте Git-flow

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

Единая версия в производстве простое ПО - используйте Github-flow

Если в вашем коде постоянно используется только одна версия (например, веб-сайты, веб-службы и т. Д.), Вы можете использовать github-flow. Основная причина в том, что разработчику не нужно усложнять задачу. Как только разработчик завершает работу над функцией или исправляет ошибку, она немедленно переводится в рабочую версию.

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

Для большого программного обеспечения, такого как Facebook и Gmail, вам может потребоваться ввести ветки развертывания между вашей веткой и главной ветвью, где могут работать инструменты CI / CD>, прежде чем оно попадет в производство. Идея состоит в том, чтобы обеспечить большую защиту производственной версии, поскольку ее используют миллионы людей.


7
Просто добавьте в список «Gitdmz-flow» / «Git DMZ Flow»: gist.github.com/djspiewak/9f2f91085607a4859a66
Роберт Фей

1
Упомянутые компании используют магистральную систему. paulhammant.com/2014/01/08/…
PatrickWalker

1
Git DMZ flow больше похож на Gitflow, а ветвь DMZ похожа на ветку разработки. Следовательно, я ничего особенного в этом не чувствую.
Gayan Pathirage

2
Насколько я понимаю, Git-Flow плохо работает с многопродуктовой версией. Стратегия исправлений предполагает, что у вас есть только одна производственная версия, и вы выполняете исправление в соответствующей ветке выпуска (а затем объединяете ее обратно в ветку разработки). Кажется, не подходит, как вы можете исправить одну ошибку, которая существует в нескольких производственных ветках.
Адриан Шум

5
@GayanPathirage На самом деле это не так. 1. "классические" теги GitFlow в мастере. Ветка исправлений предназначена только для того, чтобы вы исправили последнюю производственную версию (от мастера). 2. «ветвь выпуска» означает что-то еще в Gitflow, которое на самом деле является ветвью предварительного просмотра перед выпуском (ответвление от ветки разработки и направленное на слияние с мастером, когда оно действительно выпущено). 3. То, что вы имеете в виду, называется «ветвью поддержки» в GitFlow (это одна из причин, по которой мне не нравится GitFlow: нетрадиционная терминология). Однако это все еще экспериментальный поток (так что вы не видите его в большинстве вступлений Gitflow)
Адриан Шум

38

Я использую модель git-flow более года, и все в порядке.

Но на самом деле это зависит от того, как ваше приложение будет разрабатываться и разворачиваться.

Это хорошо работает, когда у вас есть приложение с медленным процессом разработки / развертывания.

Но, например, как и GitHub, у нас есть приложение с быстрым процессом разработки / развертывания, которое мы развертываем каждый день, а иногда и несколько раз в день, в этом случае, на мой взгляд, git-flow имеет тенденцию все замедлять, и я использую GitHub. течь.

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

Существует как минимум один графический интерфейс, поддерживающий git-flow для Mac и Windows SourceTree .

В наши дни я больше склоняюсь к потоку GitHub из-за его простоты и легкости управления. Кроме того, из-за «частого развертывания на ранней стадии» ...

Надеюсь это поможет


+1. Я согласен с тобой.
VonC

2
Поток GitHub находится в Git-Flow. Подумайте, если вам нужна непрерывная интеграция и непрерывное развертывание, вы можете просто работать как можно больше с веткой разработки. Каждая функция отделена от ветки разработки. Если у вас нет сложных моделей развертывания, вам может не понадобиться основная ветка или ветки выпуска. (например, ваша версия 1.1 работает на каком-то клиенте, ваша версия 1.2 работает на другом клиенте, и в настоящее время вы разрабатываете 1.3 для своего нового клиента) Все 3 клиента будут запрашивать исправления ошибок и изменения в их соответствующих версиях.
Gayan Pathirage 08

Привет, Диего, спасибо за ответ. А как насчет поддержки нескольких версий? Легко ли вам это удается с Git Flow? Я слышал, что это сложно, потому что вам нужны ветки поддержки! Считаете ли вы, что модель подходит для этого?
Луис Гувейя

1
Привет, Луис, я думаю, вы можете заставить модель работать, но я снова чувствую, что вы можете добиться того же с помощью стандартного рабочего процесса git.
Diego Antunes

1
На самом деле @LuisGouveia, поскольку ваш вопрос и мой ответ выше, я натолкнулся на проект, в котором git-flow будет работать отлично, и я являюсь владельцем проекта. Идея состоит в том, чтобы использовать git flow release...в сочетании с действиями github для развертывания приложения. В своем исходном ответе я упомянул, что мы выпускали несколько раз в день, это вызывало проблемы при использовании git-flow. Причина, по которой я думаю, что git-flow будет хорошо работать в этом проекте, заключается в том, что у нас есть заранее определенный цикл выпуска, который является одним из основных аргументов в пользу использования git-flow.
Диего Антунес
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.