Я работаю над командой с большой базой Java-кода (300k + строк кода), которая недавно приняла Git в качестве исходного элемента управления (перенесена из ClearCase). Мы используем Git Flow как нашу стратегию ветвления. Есть несколько вариантов использования, с которыми мы сталкиваемся довольно часто, с которыми мы боролись.
-
Мы объединили все наши функции в ветку разработки, которая будет использоваться в предстоящем выпуске. Когда мы приближаемся к релизу, оказывается, что одна функция не может жить (из-за того, что клиент не готов или какая-то другая причина). Какой лучший способ создать ветвь релиза, но оставьте конкретную функцию (во многих коммитах)? Эта функция должна быть доступна для включения в следующий будущий выпуск. То, что мы пробовали раньше, состоит в том, чтобы сделать "git revert" для всех коммитов, создать ветвь освобождения, а затем выполнить "git revert" на отмененных фиксациях. Это довольно болезненный подход, особенно для больших возможностей.
-
Мы уже создали ветвь релиза, но до того, как релиз идет в прямом эфире, он решил, что функция должна быть удалена. Подобно первому варианту использования, эта функция должна иметь возможность перейти к следующей версии. Из-за этого просто выполнение "git revert" в коммитах полностью не разрешает его, так как возврат будет сгенерирован обратно в ветвь разработки, когда мы закончим выпуск < git.
Как указано в модели Git Flow, все фиксации производятся на ветвях функций и никогда не находятся непосредственно на ветке разработки. Когда функция завершена и готова к следующей версии, она затем объединяется для разработки. Когда придет время для следующего выпуска, ветвь релиза создается без разработки. После того, как релиз был протестирован с регрессией и, при необходимости, исправлен, он переходит к производству и объединяется с мастером, а затем развивается в случае исправлений ошибок и помечен номером версии. Проблемы выше, когда функция, которая, как мы думали, идет в следующем выпуске, заканчивается тем, что ее нужно оставить без внимания.
Каковы наилучшие методы обработки этих ситуаций? В обоих этих сценариях ветки были опубликованы и сняты многими разработчиками, поэтому испорченность историей может создать трудности. Я знаю, что они менее идеальны, но, к сожалению, ситуации не поддаются контролю.