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