Стратегии ветвления и слияния

Обзор

В этой лекции представлены стратегии ветвления и слияния для некоторых типичных сценариев. Как правило, ветвление нужно для поддержки выпусков или параллельных разработок.

Во многих простых сценариях ветвление не требуется. Вполне достаточно помечать сборки. Например, при помощи метки можно в любой момент заново создать сборку или выяснить, какие версии исходного файла были использованы при создании той или иной сборки. Следует подумать о ветвлении, если вам требуется изолирование параллельных групп для работы над разными, но перекрывающими функциями или для поддержки выпуска.

Чтобы в целом познакомиться с ветвлением и слиянием, читайте лекцию от начала до конца. Так вы узнаете о различных стратегиях ветвления и различных сценариях, при которых ветвление имеет смысл. Если вас интересует конкретный сценарий, перейдите к соответствующему разделу.

Сценарии ветвления и слияния

Ниже представлены примеры сценариев, в которых может потребоваться создание ветвей и выполнение слияний:

• Если вы постоянно сталкиваетесь с проблемой сломанных сборок, создайте ветвь разработки, чтобы изолировать параллельные варианты разработки.
• Если при выполнении некоторых функции или взаимодействии некоторых групп возникают проблемы с устойчивостью, создайте для этих функций или групп отдельные ветви в папке разработки системы управления исходным кодом.

Не выполняйте ветвление без необходимости, поскольку оно добавит вам работы по обслуживанию дополнительного дерева исходного кода и по слиянию. Большинство групп разработчиков, создающих коммерческие приложения, работают по короткому циклу выпуска и не нуждаются в ветвлении. Команды разработчиков, работающие с более продолжительными циклами, например, независимые поставщики ПО, чаще нуждаются в ветвлении.

При использовании одного потока разработки или осуществлении инкрементного и непрерывного выпуска ветви следует создавать ветви, только если изменения часто приводят к сбоям и вносят неустойчивость в процесс разработки.

Типичные сценарии

Ниже приведены наиболее типичные сценарии ветвления:

• Сценарий 1 - без ветвей. Команда работает только из главного дерева исходного кода. В этом случае вы не создаете ветвей и не нуждаетесь в изоляции. Данный сценарий соответствует, главным образом, мелким и средним командам, не требующим изолирования групп, функций или выпусков.
• Сценарий 2 - ветвь выпуска. Команда создает ветви для текущего сопровождения выпуска. Это наиболее распространенная ситуация. В этом случае ветвь создается для обеспечения устойчивости очередного выпуска до его выхода, а затем опять сливается с главным деревом исходного кода.
• Сценарий 3 - ветвь сопровождения. Команда создает ветвь для обслуживания предыдущей сборки, чтобы делать это, не нарушая устойчивости текущих сборок. Обратное слияние изменений ветви сопровождения с главным деревом производится при необходимости. Допустим, оно не нужно, если вы вносите для группы клиентов специфические оперативные изменения, который не хотите включать в главную сборку.
• Сценарий 4 - ветвь функции. Команда создает ветви, основываясь на функциях. То есть, вы создаете ветвь разработки, выполняете в ней нужную работу, а затем производите слияние с главным деревом исходного кода. Вы можете создавать самостоятельные ветви для работы над отдельными функциями, окончательная доработка которых будет происходить параллельно.
• Сценарий 5 - ветвь группы. Ветви создаются для изолирования подгрупп, чтобы они могли работать, не мешая друг другу или двигаясь параллельно к различным контрольным точкам.

Вы можете столкнуться как с одним, так и с несколькими из этих сценариев. Используйте их в качестве ориентира.

Примеры папок и их назначение

В этом разделе приведены примеры папок, создаваемых в системе управления исходным кодом Microsoft Visual Studio® Team Foundation Server (TFS) при структурировании дерева кода по сценариям ветвления и слияния.

• Папка Main содержит главное дерево исходного кода. Здесь соединяются изменения из других ветвей.
• Папка Development является ответвлением Main и используется для изолирования текущей разработки. Подобные ветви могут создаваться временно, например, для проверки рискованных изменений, без влияния на Main.
• Папка Releases содержит ветви выпусков, которые уже осуществлены, и сейчас осуществляется поддержка клиентов. Она обеспечивает изоляцию текущей разработки, которая ведется в ветви Development, а также содержит ветвь текущего выпуска, которая отделена от Main и хранит версию, заблокированную до выпуска. В этой ветви вы готовите ПО к выпуску, тогда как остальные продолжают работать в ветви Development над новыми функциями.

В следующих разделах на конкретных примерах показано использование ветвления в каждом из описанных сценариев.

Сценарий 1 - без ветвей

Этот сценарий применяется, в основном, в небольших группах, где не нужна изолированная разработка. Помечая сборки, вы можете извлекать исходный код, соответствующий конкретной сборке. В ветвлении нет нужды, поскольку вы можете работать напрямую из папки Main. Ниже приводится структура папок в сценарии без ветвления:

{
My Team Project 
Main
Source 
}

Сценарий 2 - ветвь выпуска

В этом сценарии команда создает ветвь для стабилизации выпуска, а затем, после выпуска программы, производит слияние ветви с главным деревом исходного кода. Ниже приводится структура папок в сценарии ветвления выпусков:

}
My Team Project
Main	->Главная ветвь сборки
Source
Releases 
Release 1        ->Ветвь выпуска 
Source 
}

Сценарий 3 - ветвь сопровождения

В этом сценарии вы создаете ветвь для сопровождения, чтобы не нарушить устойчивость текущих сборок. Далее показана структура папок с ветвлением для сопровождения. Она очень похожа на структуру с ветвлением для выпуска, однако сохраняется на более продолжительное время:

}
My Team Project
Main         - >Главная ветвь сборки
Source
Releases	->Контейнер для ветвей сопровождения
Release 1     ->Ветвь сопровождения 
Source
Другие папки ресурсов 
Release 2      ->Ветвь сопровождения 
Source
Другие папки ресурсов 
}

Сценарий 4 - ветвь функции

В этом сценарии вы создаете ветвь разработки на основе функций продукта, выполняете в ней работу, а затем производите слияние с главным деревом исходного кода. Ниже приводится структура папок в сценарии ветвления с целью разработки функциональных особенностей:

{
My Team Project 
  Development	->Изолированный контейнер ветвей разработки
    Feature A	->Ветвь функции
      Source 
    Feature B	->Ветвь функции
      Source 
    Feature C 	->Ветвь функции
  Main		->Главная ветвь сборки
Source 
}

Сценарий 5 - ветвь группы

Этот сценарий похож на сценарий ветвления по функциям, за исключением того что здесь вы организуете ветви разработки не по функциям конечного продукта, а в соответствии с подгруппами основной команды разработчиков. Иногда группы и функции точно соответствуют друг другу, но в других случаях группа может работать над несколькими функциями. Ниже приводится структура папок в сценарии ветвления по группам:

{
My Team Project
   Development       	->Изолированный контейнер ветвей разработки
      Team 1	-> Ветвь группы
          Feature A	-> Изолированная ветвь разработки
              Source
          Feature B	-> Изолированная ветвь разработки
              Source
              Team 2	-> Ветвь группы
          Feature A	-> Изолированная ветвь разработки
              Source
          Feature B	-> Изолированная ветвь разработки
              Source
              Main	-> Главная ветвь сборки
            Source
}