Согласование Branch-per-task и исправление ошибки, когда ошибка была исправлена ​​и объединена с транком, но на самом деле ошибка была недостаточно "исправлена"

Question

Я недавно переключился с CVS на Plastic для контроля версий. Мы используем Jira для отслеживания проблем, а пластиковые ветви - для связи наборов изменений с открытыми проблемами. Благодаря этому переключателю я также применил подход к разработке для каждой задачи. Это привело к интересной дилемме, когда дело доходит до исправления ошибок, которые были повторно открыты (новый тестовый случай обнаружил, что ошибка не была полностью исправлена ​​после итерации / выпуска для тестирования)

Я исправил ошибку, выполнил свои тесты (доступные в то время) против нее, и она прошла. Я объединил код и разработал вторую функцию, которая затрагивала тот же файл. Оба изменения были сделаны в разных ветках, и оба были успешно объединены в основную ветку сборки. Новая сборка идет в QA, и они обнаруживают немного другой способ воспроизвести ту же проблему (новый контрольный пример) и заново открыть ошибку. Исходная ветка ошибок не включает новые функции, добавленные в один и тот же файл, потому что они находятся в разных ветках (например, исправления ошибки 1 являются частью ветви функции 2 [так как эта ветка была создана после того, как оригинальное исправление было объединено с веткой сборки], но новый код функции 2 отсутствует в ветке ошибок 1)

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

• Было бы лучше клонировать ошибку в Jira, чтобы создать новую проблему
  номер, создать новую ветку и исправить проблему, как будто она новая?
  [это будет по существу основывать новое исправление на комбинации
  оригинальное исправление + новая функция] (затруднит ли это слияние
  между версиями, если вам пришлось отслеживать несколько исправлений для одного и того же
  вопрос?)
• Было бы лучше вернуться к первоначальной ветке, где
  исходная проблема была исправлена, и исправьте ее заново, затем снова объедините,
  с разрешением конфликтов каждый раз, когда такое происходит?

Замечания:

1. Ветви создаются для связи с системой отслеживания ошибок (Jira), поэтому имена ветвей включают номер выпуска.
2. Из-за этой ссылки я не могу создать 2 ветки с одинаковыми именами, если у них нет разных родителей. Таким образом, я мог бы создать вторую ветку из оригинальной, но не из ветки сборки (которая является родителем исходной проблемы)

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

Держу пари, что это не будет обычным явлением для одного разработчика, но это может происходить чаще с большими командами, даже если это не определенно между ошибкой и функцией (возможно, две функции могут влиять на один и тот же файл)), вызывая дополнительное разрешение конфликтов в течение жизненного цикла сборки / тестирования перед выпуском)

Этот процесс работает почти противоположно тому, как команда использовала CVS в прошлом, поэтому я пытаюсь найти "правильный" способ сделать это, чтобы минимизировать боль при продвижении с новой моделью. Раньше я просто собирался получить последние изменения из последней сборки и внести новое исправление - таким образом, избегая любых проблем разрешения конфликтов (но я не получаю преимущества ветвления на задачу).

Теперь мне нужно подумать о том, в какой ветке было сделано "оригинальное" исправление, и если это правильное место, где "новое" исправление должно идти, чтобы синхронизировать систему отслеживания проблем со списком изменений.

Answer 1

Есть несколько альтернатив и решений для ситуации, которую вы спрашиваете, я собираюсь объяснить мой любимый вариант для каждой ситуации, которую я могу придумать:

(1) 2 ветви интегрированы в "ветвь релиза" AKA "/main", и вы не хотите их вычитать.

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

Теперь, когда у вас есть новое задание в Jira, вы можете создать новое отделение в Plastic. Эта новая ветвь будет основана на последнем cset / label в ветке "/ main".

Разработайте исправление и интегрируйте его в следующем выпуске, когда на нем будет все зелёное.

(2) Задачи не могут оставаться в "ветке Release", и они должны быть вычтены

Вы выполните вычитающее объединение наборов изменений, созданных в ветви "/ main", поэтому "ветвь релиза" будет возвращена к устойчивой точке.

Задача Jira вновь открывается, даже переоценивается.

Разработчик продолжит работу в ветке задач, чтобы привести код в соответствие с новыми требованиями.

Как только задача завершена, начинается обычный цикл ветвления на задачу.

Надеюсь, поможет!