Создайте ветку исправлений или функциональную ветвь в модели gitflow - PullRequest
Новая
       16

Создайте ветку исправлений или функциональную ветвь в модели gitflow

2 голосов
/ 21 марта 2019

Я использую эту модель в моей команде: enter image description here

Сегодня моя статистика проекта следующая:

  • Стабильная версия запущена в производстве с использованием главной ветки
  • Мы разработали новые функциональные возможности, которые необходимо протестировать перед производством, поэтому у нас есть ветка релиза, которая будет тестироваться в SIT Environment . Эти новые функции просто можно объединить с мастером после всех испытаний в среде SIT.

Проблема: Владелец продукта запросил новое поле в Таблице в производстве. Поэтому команда предлагает два решения:

  • Создайте ветку исправлений из master, добавьте новое поле и разверните в Test Environment . Это исправление может ждать месяцы до слияния с мастером, потому что после теста нам нужно дождаться, когда Владелец продукта скажет, что может перейти в производство, поскольку это поле зависит от изменений другой системы.

  • Создайте ветку компонентов из разработки, добавьте это новое поле и разверните в Тестовой среде . Я думаю, что это худшее решение , потому что у меня есть вещи в разработке, которые нельзя объединить с мастером, поэтому мне понадобится cherry-pick , чтобы забрать только желаемое изменение с момента выпуска освоить. Помните, что команда проверяет функциональность других в SIT Environment (ветвь релиза).

1 Ответ

3 голосов
/ 21 марта 2019

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

Несчастная большая проблема не в слиянии, а в функциях, которые невозможно освоить. Как я могу отправить только это изменение, не отправляя все другие функции в ветке разработки или выпуска?

Это означает, что gitflow не является рабочим процессом для вас.
Переключитесь на рабочий процесс (одно слово, , показанное здесь ).
Подробнее на rocketraman/gitworkflow.

Такого рода рабочий процесс (где вы не объединяете dev до master, но где вы объединяете только ветвь объекта до dev, затем, если выбрано, до master, чтобы иметь возможность отбрасывать легкие ветки, не готовые к следующему выпуску) реализованы в самом репозитории Git.

https://github.com/rocketraman/gitworkflow/raw/master/docs/images/topicgraduation.png

(источник: Рабочий процесс: учебник для начинающих, ориентированный на задачи )

У вас есть:

  • master - это ветка, готовая к развертыванию в рабочей среде в любое время: следующий выпуск с выбранным набором ветвей функций, объединенных в master.
  • dev (или ветвь интеграции, или 'next') - это та, в которой ветвь функций, выбранная для следующего выпуска, тестируется вместе
  • maintenance (или hot-fix) - это ветвь для текущего выпуска / исправлений ошибок, с возможным слиянием до dev и или master

Примечание: в этом распределенном рабочем процессе вы можете фиксировать в любое время и передавать в личную ветку некоторые WIP (Work In Progress) без проблем: вы сможете реорганизовать (git rebase) ваши коммиты, прежде чем сделать их частью ветвь функций.

...