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