В чем разница между GitHub Flow и GitLab Flow?

Недавно я нашел три концепции рабочего процесса в GIT: GitFlow, GitHub Flow и GitLab Flow. Я прочитал эту статью (https://docs.gitlab.com/ee/workflow/gitlab_flow.html), но я не очень хорошо понимаю GitLab Flow. Может быть, потому что я не носитель языка:)

Коротко.

GitFlow (https://docs.gitlab.com/ee/workflow/gitdashflow.png).

У нас есть филиал мастера как производственная отрасль. Также у нас есть отрасль разработки, где каждый разработчик объединяет свои функции. Иногда мы создаем ветвь выпуска для развертывания наших функций в процессе производства. Если у нас есть ошибка в ветки релиза, исправьте ее и потяните за изменения в ветку разработки. Если у нас есть критическая ошибка в производстве, создайте новую ветку исправлений, фикцию ошибок и слияние с производством (master) и создайте ветки.

Этот подход очень хорошо, если мы редко показываем результаты нашей работы. (Может быть, время в 2 недели).

GitHub Flow (https://docs.gitlab.com/ee/workflow/github_flow.png).

У нас есть филиал мастера как производственная отрасль. И мы (как разработчики) можем создавать ветки для добавления новых функций или исправления ошибок и объединения их с производственной (основной) ветвью. Звучит очень просто. Этот подход подходит для экстремального программирования, когда производственная ветвь развертывается несколько раз в день.

GitLab Flow (https://docs.gitlab.com/ee/workflow/production_branch.png, https://docs.gitlab.com/ee/workflow/environment_branches.png, https://docs.gitlab.com/ee/workflow/release_branches.png).

Я видел новые термины, такие как предварительная, производственная, релизная (стабильная) ветвь и промежуточная среда, предпроизводственная среда, производственная среда. Какие отношения между ними существуют?

Я так понимаю: если нам нужно добавить новую функцию, мы разворачиваем предпроизводственную ветку из главной ветки. Когда мы закончим эту функцию, мы разворачиваем производственный отдел из предпроизводственного ветки. Предпроизводственная отрасль - промежуточный этап. И тогда главная ветвь выведет все изменения из производственной ветки.

Подход хорош, если мы хотим видеть каждую отдельную функцию. Мы просто проверяем в ветке, что нам нужно и смотрим.

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

Является ли мое видение правильным? Какая разница между тягой и вишневым выбором?

Ответы

Ответ 1

GitLab Flow предлагает использовать ветки master и feature. После того, как функция будет выполнена, мы снова объединим ее с ветвью master. Эта часть выглядит так же, как в GitHub Flow.

Тогда я понимаю, что они дают нам 2 варианта, как это сделать, в зависимости от того, является ли это приложение SAAS или мобильное приложение (которое может быть выпущено в мир).

Если это приложение SAAS, мы используем ветки среды, например. pre-production и production. Эти ветки создаются с master, когда мы готовы развернуть наше приложение. Имея разные ветки на среду, мы можем настроить инструмент CI/CD для автоматического развертывания при фиксации данных в этих ветвях. Если есть критическая проблема, мы фиксируем ее в ветке feature или master, а затем объединим ее с ветвями environment.

Что касается приложений, которые могут быть выпущены в мир (например, мобильные или настольные приложения), я понимаю, что они предлагают использовать другую модель, используя ветки release вместо ветвей среды. Мы все еще работаем в ветвях feature и возвращаем их обратно в ветвь master после завершения. Затем, когда мы уверены, что ветвь master достаточно стабильна, то есть мы уже выполнили все тестирование и исправление ошибок, мы создаем ветвь release и выпускаем наше программное обеспечение. Если есть критическая проблема, мы сначала исправим ее в ветке master и вишневом выберите исправление для ветки release.

Ответ 2

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

GitHub Flow как изначально изображенный Скоттом Чаконом в 2011 году предполагал каждое изменение после рассмотрения на feature branch и объединены в master, должны быть немедленно установлены на производство. В то время как это работало в то время и соответствовало единственному правилу GitHub Flow, которое является чем-либо в главной ветки, можно развертывать, было быстро обнаружено, что чтобы сохранить master истинную запись известного рабочего производственного кода, фактическое развертывание для производства должно происходить от feature branch до, сливая его в master. Развертывание из feature branch имеет смысл, так как в случае любой проблемы производство может быть мгновенно отменено путем развертывания master к нему. Пожалуйста, посмотрите краткое визуальное введение в GitHub Flow.

GitLab Flow является продолжением GitHub Flow, сопровождаемым набором рекомендаций и рекомендаций, которые цель дальнейшей стандартизации процесса. Помимо продвижения готовых к развертыванию ветвей ветвей и ветвей master (таких же, как GitHub Flow), он вводит три других типа ветвей:

Я верю, что имена и примеры являются самоописательными, поэтому я не буду подробно останавливаться.