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

Ответ 1

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

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

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

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

Короче говоря:

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

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

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

Фактически более полный и надежный рабочий процесс см. gitworkflow (одно слово).

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

Ответ 4

Я работал с "От Micro до Macro - модель ветвления GIT и рабочий процесс" и нашел это очень полезным для веб-сайтов и проектов веб-сервисов.