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

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

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

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

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

Как обсуждалось в эпизоде ​​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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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