Выбор стратегии ветвления и слияния в Team Foundation Server (TFS)

Как использовать данную статью

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

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

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

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

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

Не следует использовать ветвление, если в нем нет крайней необходимости. Ветвление требует дополнительного обслуживания каталога исходного кода и выполнения задач по слиянию. Для большинства групп разработки, которые занимаются созданием бизнес-приложений и имеют короткие циклы выпуска новых версий, ветвления не требуется. Группам разработки, реализующим более длинные циклы выпуска, таким как Независимые производители ПО (Independent Software Vendors, ISV), которые создают «коробочные» приложения, скорее всего, придется прибегнуть к ветвлению в своем процессе разработки.

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