GitFlow, как обрабатывать отмененные функции, которые объединяются для разработки - PullRequest
Новая
       22

GitFlow, как обрабатывать отмененные функции, которые объединяются для разработки

0 голосов
/ 22 мая 2018

Из следующих фрагментов, взятых из здесь

готовые функции и исправления объединяются обратно в ветку разработки, когда они готовы к выпуску

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

Когда приходит время делать релиз, ветвь релиза создается вне разработки

И в этой строке ожидается выпуск функций в ветви разработки.

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

Я знаю, что выполнение git revert может помочь в этом.Мне довелось испытать это давным-давно (хотя я уже забыл, что я делал за это время), но я использую экспериментальный пользовательский рабочий процесс, который предотвращает подобные случаи.

экспериментальный пользовательский рабочий процесс Worlflow 1

Поток, который я экспериментирую, почти такой же, как gitflow, за исключением части, в которой "функции объединены для разработки".В этом экспериментальном рабочем процессе он заменяется «проверенными работающими функциями объединены для разработки»

Поток становится таким:

  1. Все функции должны бытьвыпущенный или протестированный QA помещен ( не объединен ) в ветку для тестирования (разработка ветки + все функции, которые будут выпущены)
  2. Проверенные функции объединено для разработки
  3. Новые ветви функций созданы из разработки

Это работает нормально для меня, но есть незначительныйпроблема.Он создает дубликаты коммитов при каждой перебазировке.Я пробовал cherry-pick, merge (с ff) и pull --rebase, но все тот же результат.

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

Это почти то же самое с рабочим процессом выше

Рабочий процесс 2

  1. Все функции, которые будут выпущены или протестированы QA, объединены в ветвь, скажем предварительная разработка

  2. Проверенные функции: вишня для разработки

  3. Новые ветви функций созданы из предварительной разработки , поскольку она содержит все функции (истекающий кровью)

Это не идеально, но делает мою жизнь немного легче, по крайней мере, сейчас.

Мысли об этом?Есть ли у вас лучшие альтернативы для этого сценария?

1 Ответ

0 голосов
/ 22 мая 2018

Давайте посмотрим, как новые изменения перемещаются между ветвями

Обычный поток операций:

  • разработка -> функция

  • функция -> разработка

  • разработка -> выпуск

рабочий процесс 1:

  • разработка -> функция

  • функция -> функция для проверки

  • функция для проверки -> разработать

, поэтому от функции к разработке уходит:

  • разработка -> функция -> функция ктест -> разработка

Здесь мы видим дублирующие коммиты с rebase

рабочий процесс 2

  • предварительная разработка-> Feature
  • Feature -> Cherrypicked-> Develop

Это кажется странным, я не видел такого подхода раньше.Это может сработать, я не уверен.

Однако я думаю, что лучше всего придерживаться классического потока мерзавцев, и если вам нужно удалить ветку объектов, используйте revert.Также могут помочь ответы на эти вопросы:

https://softwareengineering.stackexchange.com/questions/295202/what-happens-if-a-feature-merged-into-develop-is-postponed-by-management

Git-Flow отменяет готовую ветку объектов

...