GitHub Flow и релизы

Question

Мы относительно новичок в git в целом. Мы использовали его около 6 месяцев и использовали GitHub и BitBucket. Мы старались учиться как можно больше, используя GitBash, чтобы мы могли попасть под ядро ​​git.

Мы находимся на этапе, когда мы действительно хотим рассмотреть нашу стратегию ветвления, и, следовательно, я занимаюсь некоторыми исследованиями.

По моему мнению, GitFlow слишком сложна для наших требований. Мы работаем над 20 различными проектами в целом, и каждый проект может иметь только релизы каждые 2 месяца или около того. Посмотрев на GitHub Flow, это выглядит довольно прямолинейным вариантом, который бы соответствовал нашим потребностям - однако, похоже, у него есть недостаток, который я бы хотел услышать от людей.

Все, что находится в ведущей ветке, развертывается. Мы развертываем в средах UAT/QA, где эта версия может оставаться в течение 3-4 недель, в зависимости от того, сколько времени потребуется клиенту и/или нам, чтобы подписать все. Тем временем кому-то еще может понадобиться работать над чем-то совершенно другим. На этом этапе, основываясь на потоке Github Flow, если этот пользователь взял ветку от Мастера, они будут включать изменения, которые на самом деле в данный момент находятся в среде QA. Итак, я понял, что я не понял первую точку GitHub Flow - то есть что-либо в главной ветке развертывается - возможно, это только кольцо true, если код прошел через QA и т. Д.?

Если это так, то ли поток на самом деле больше похож ?:

• Возьмите ветку от Мастера
• Фиксировать изменения в отрасли (только обратно в филиал на данном этапе)
• Merge филиал с отдельным подразделением под названием «Разработка»
• Освобождение от QA/UAT
• Когда разрешение одобрено, слияние ветки с мастером и развертывание?

Я думаю, что это конкретно пункт 1 в GitHub потоке, что сбивает с толку - мы, конечно, не следует отодвигать к Учителю, когда выпуск еще в QA - что бы мастер ветвь потенциально нестабильным и, конечно, не то, в настоящее время в производстве.

Answer 1

В соответствии с тем, что я вижу на git-flow cheat sheet и Driessen's original model, у вас есть кое-что не так.

В то время как я не использовал рабочий процесс git-flow сам, из того, что я могу сказать, master сливается только тогда, когда релиз готов, а НЕ раньше. Таким образом, masterвсегда отражает то, что находится в Prod - develop - это то, что служит «основной» ветвью развития, из которой вытягиваются и объединяются ветки функций.Таким образом, успешный git-flow рабочий процесс выглядит примерно так (при условии, все эти отрасли существуют заранее, если не указано иное):

1. Создать функцию ветвь (которую мы будем называть topic) от develop
2. Работа на topic для некоторое время
3. Merge topic обратно в develop
4. Сделайте это несколько раз, пока вы не будете готовы к выпуску
5. Создать новую ветку, QA-releaseno, от develop
6. Do QA/UAT на QA-releaseno, совершая исправления ошибок по мере необходимости (можно также объединить QA-releaseno обратно в develop столько раз, сколько вам угодно)
7. Когда вы будете готовы отпустить, объединить QA-releaseno в оба master и develop, помечать релиз master и удалять QA-releaseno

Кроме того, что вы, кажется, сделали это приравнивать git-flow и Chacon's GitHub flow. GitHub поток, по крайней мере, в своей простейшей форме, как это работает:

1. закрутить новую тему ветвь (здесь называется topic) от master
2. Работы на topic (если вы работаете на нем в течение длительного время, сливаясь master обратно в нее периодически хорошая идея)
3. Do QA на topic
4. Потушить запрос тянуть (PR) от topic к master
5. После того, как PR был код рецензируемых всем satisfcation «s, слейте topic назад master
6. Release master сразу, или по крайней мере прилично быстро

Этот рабочий процесс предназначен для групп и организаций, которые находятся на цикле быстрого высвобождения (несколько раз в неделю). QA выполняется не на уровне приложения, а на уровне отдельной функции, задачи или билета. Поскольку цикл выпуска имеет немедленную (или, по крайней мере, быструю) обратную связь, master всегда будет отражать то, что в производстве.