За и против продвижения версии по сравнению с ответвлениями версии

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

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

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

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

На мой взгляд, эти два являются исключительными.

Механизм ветвей версий необходим, если вам нужно поддерживать разные ВЫПУЩЕННЫЕ версии. Но я думаю, что лучше всего всегда готовить точку ветвления (в зависимости от вашей системы версий) после выпуска версии.

Механизм «продвижения» необходим, если вам нужно выпустить тестовую версию. Это полезно, если у вас есть, например, группа проверки, отличная от команды разработчиков и / или большой команды, где разработка идет быстро. В этих случаях вам понадобится определенная ветка для стабилизации следующего «стабильного» выпуска, в то время как магистраль останется «нестабильной».