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

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

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

мы рассматриваем возможность перехода на GitHub-flow, но я хочу убедиться.

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

3 ответов


как обсуждалось в gitminutes эпизод 17, по Николай Zakas в своей статье на "рабочие процессы GitHub внутри компании":

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

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

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

короче:

начните с модели как можно более простой (например, поток GitHub имеет тенденцию быть) и перейдите к более сложной модели, Если вам нужно.


вы можете интересная иллюстрация простой рабочий процесс, основанный на GitHub-Flow at:
"простая модель ветвления git", С основными элементами которой являются:

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

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


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

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

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

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

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

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

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


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

но это действительно зависит от того, как будет разработано и развернуто ваше приложение.

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

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

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

существует по крайней мере один GUI, который поддерживает git-flow для Mac и Windows SourceTree.

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

надеюсь, что это помогает