Git flow разъяснения о существовании как Hotfix, так и RC? - PullRequest
Новая
       22

Git flow разъяснения о существовании как Hotfix, так и RC?

1 голос
/ 09 марта 2019

Общий подход к существованию как RC, так и Hotfix:

Исправление не должно существовать (или может, но очень скоро) одновременно с ожидающим RC.

Глядя на это изображение:

enter image description here

Что, если имеется ожидающий RC, который находится на стадии подготовки и еще не был полностью протестирован, и внезапно возникает необходимость в срочном исправлении?

Конечно, тогда мы создадим ветку исправлений, исправим ее и вернемся к dev и master.

Но как насчет ожидающего RC?

  • Не содержит изменений.
  • Git flow говорит, что мы не должны объединять исправление с RC
  • Мы не можем доверять исправлению на главном, потому что, строго говоря, RC должен быть загружен и протестирован в целом.

Итак, мы должны отменить RC? но тогда dev не будет таким, каким он был, когда RC был разветвлен

Вопрос

Предполагая, что имеется ожидающее не полностью протестированное RC и срочное исправление, что нужно сделать с точки зрения RC?

Даже если мы загрузим RC (без исправления) в master (который содержит исправление) - только следующий RC будет содержать исправление (из-за слияния разработчика с исправлением) - но это говорит о том, что RC который никогда не тестировался с исправлением - будет загружен !!!

Я не нашел такой информации о подобных сценариях.

Как мы должны иметь дело с RC и исправлениями?

Ответы [ 2 ]

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

Вот почему вы не используете gitflow.

Если у вас есть такая нелинейная разработка с внеплановыми усилиями по разработке (например, исправление), вы должны использовать « gitworkflow » (одно слово, также , представленное здесь ): рабочий процесс, используемый самим репозиторием Git .

С Gitworkflow ваш RC будет в master, а ваше исправление в maint ветви , которое (вопреки Git Flow) может быть затем объединено в master если нужно.
(примечание: не все исправления необходимо переносить обратно / объединять в master или dev: иногда вы исправляете в текущем производственном выпуске что-то, что больше не актуально в следующем цикле разработки ).

Другое отличие от Git Flow: ветви "public" и "next" (он же 'devel') никогда не объединяются в master. Они «временные» или «эфемерные», всегда удаляются / воссоздаются.
Только ветви объектов объединяются с ветвями жизненного цикла (public, next, master). Это означает, что в любой момент вы можете отказаться от функции между одним этапом жизненного цикла разработки и следующим.
И master может получить слияние от 'maint' (исправления) в любое время.

Затем dev (называемые next) и pu (для экспериментов) просто сбрасываются / воссоздаются, с их соответствующими ветвями выбранных объектов, уже объединенными в них, с Git 2.18 приносит git rebase --rebase-merges.

1 голос
/ 09 марта 2019

Вы говорите:

Поток Git говорит, что мы не должны объединять исправление с RC.

Но читая страницу Gitflow Я прочитал прямо напротив в "Завершение ветки исправлений":

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

Так что проблем нет: -)

...