GitHub Flow и релизы

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

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

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

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

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

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

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


git github git-flow
person dotdev    schedule 28.11.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Согласно тому, что я вижу в git-flow шпаргалке и исходная модель Дриссена, вы ошиблись в нескольких вещах.

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

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

Кроме того, вы, кажется, объединили git-flow и поток GitHub Чакона. Поток GitHub, по крайней мере, в его простейшей форме, работает следующим образом:

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

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

person Sebastian Lenartowicz    schedule 28.11.2016
comment
Вы не имеете в виду GitFlow, а не GitHub Flow? scottchacon.com/2011/08/31/github-flow.html - person dotdev; 28.11.2016
comment
@dotdev: Мне кажется, что OP удалось спутать git-flow и поток GitHub, отсюда и его замешательство. Я обновил ответ. - person Sebastian Lenartowicz; 28.11.2016
comment
Я думаю, что это звучит так, как будто я перепутал их, потому что я представил концепцию наличия ветки разработки, которую с таким же успехом можно было бы назвать DevReleases. Причина, по которой я представил это в GitHub Flow, заключается в том, что если мы хотим развернуться в QA (используя TeamCity и Octopus), в идеале мы не хотим обновлять TeamCity каждый раз, чтобы посмотреть на новую ветку функций, т. е. было бы намного проще, если QA выпускает всегда были из ветки разработки. - person dotdev; 28.11.2016
comment
@dotdev: то, что вы видите, представляет собой своего рода гибридный рабочий процесс, который не является ни git-flow, ни потоком GitHub - верно? В этом, конечно, нет ничего плохого, но рекомендация конкретного потока выходит за рамки ответа SO (поскольку это будет в первую очередь основано на мнении). - person Sebastian Lenartowicz; 29.11.2016
comment
Спасибо за все Ваши ответы. Если наличие ветки Release только для выпусков QA отличается от GitHub Flow, то я полагаю, вы правы, это гибрид. Я полагаю, что хотел уточнить, а также пытался выяснить, каковы потенциальные риски этого потока. Мы сами подчеркнули, что потенциально ветвь 1 и ветвь 2 могут быть объединены в ветвь Релизы почти случайно, поэтому тесты контроля качества могли протестировать и утвердить обе ветви вместе, но ни ветвь 1 или ветвь 2 по отдельности. - person dotdev; 29.11.2016