Выбор стратегии ветвления и слияния в Team Foundation Server (TFS) - Примеры именования папок и их назначение

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

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

• Папка Development ответвляется от Main и используется для изолирования кода, находящегося в активной разработке. Ветви разработки могут быть временными и создаваться только на период работы над опасными изменениями, чтобы не оказывать влияния на содержимое папки Main.
• Папка Main содержит основной каталог исходного кода. Все изменения из остальных ветвей интегрируются здесь.
• Папка Releases содержит ветви с уже выпущенным кодом, который теперь требуется обслуживать. Она изолирует этот код от кода, размещающегося в ветви разработки и участвующего в активной разработке. Также в этой папке находится ветвь текущей версии, которая ответвляется от 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 
            Other Asset Folders 
        Release 2                       -> Ветвь обслуживания 
            Source 
            Other Asset Folders 

Сценарий 4 – Ветвление для разработки функциональной возможности

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

My Team Project 
    Development         -> Контейнер ветви изолированной разработки 
        Feature A       -> Ветвь функциональной возможности 
            Source 
        Feature B       -> Ветвь функциональной возможности 
            Source 
        Feature C       -> Ветвь функциональной возможности 
            Source 
    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