Ответ зависит от размера вашей команды и качества вашей системы управления версиями, а также от способности правильно объединять сложные наборы изменений. Например, при полном управлении исходным кодом ветви, таком как слияние CVS или SVN, может быть сложно, и вам может быть лучше с первой моделью, в то время как при использовании более сложной системы, такой как IBM ClearCase, и с большим размером команды вам может быть лучше со второй. модель или их комбинация.
Лично я бы разделил модель ветвей функций, где каждая основная функция разрабатывается в отдельной ветке, с вложенными ветвями задач для каждого изменения, выполняемого отдельным разработчиком. По мере того, как функции стабилизируются, они объединяются в ствол, который вы поддерживаете достаточно стабильным и постоянно проходите все регрессионные тесты. Когда вы приближаетесь к концу цикла выпуска, и все функциональные ветви сливаются, вы стабилизируете и разветвляете ветвь системы выпуска, в которой вы только исправляете ошибки стабильности и необходимые резервные копии, в то время как магистраль используется для разработки следующего выпуска, и вы снова ответвление для новых функциональных веток. И так далее.
Таким образом, магистраль всегда содержит последний код, но вам удается поддерживать его в разумной степени стабильным, создавая стабильные метки (теги) для основных изменений и слияний функций, ветки функций быстро развиваются с непрерывной интеграцией, а отдельные подветви задачи могут часто обновляется из ветки функций, чтобы все работали над одной и той же функцией синхронно, не влияя при этом на другие команды, работающие над другими функциями.
В то же время у вас есть на протяжении истории набор веток выпуска, где вы можете предоставлять резервные копии, поддержку и исправления ошибок для ваших клиентов, которые по какой-либо причине остаются на предыдущих версиях вашего продукта или даже на последней выпущенной версии. Как и в случае с основной ветвью, вы не настраиваете непрерывную интеграцию в ветвях выпуска, они тщательно интегрируются после прохождения всех регрессионных тестов и другого контроля качества выпуска.
Если по какой-то причине две функции являются взаимозависимыми и нуждаются в изменениях, вносимых друг другом, вы можете рассмотреть возможность разработки обеих функций в одной и той же ветке функций или потребовать, чтобы функции регулярно объединяли стабильные части кода в магистраль, а затем обновляли изменения из ствол для обмена кодом между ветвями ствола. Или, если вам нужно изолировать эти две функции от других, вы можете создать общую ветвь, от которой вы разветвляете эти ветки функций и которую можно использовать для обмена кодом между функциями.
Вышеупомянутая модель не имеет особого смысла для команд до 50 разработчиков и системы управления версиями без разреженных ветвей и надлежащих возможностей слияния, таких как CVS или SVN, что сделало бы всю эту модель кошмаром для настройки, управления и интеграции.