Вопросы и ответы: система управления исходным кодом и версиями TFS

Как использовать ветвление для поддержки приложения?

Для поддержки ранее выпущенных сборок используйте ветви сопровождения. Далее приводится пример структуры ветвей после создания ветви сопровождения:

• Main - главная ветвь сборки.
  • Source.
  • Другие папки ресурсов.
• Releases - контейнер для ветвей выпусков.
  • Release 1 - ветвь сопровождения.
    • Source.

Учитывайте следующие рекомендации по работе с ветвью сопровождения:

• Когда выполнять ветвление После выпуска. Проводите обслуживание выпуска в ветви, находящейся в папке Releases.
• Когда не следует выполнять ветвление Если сопровождение выпуска не планируется, помечайте сборки старых выпусков с помощью меток и продолжайте работать в основной ветви.
• Разрешения на доступ к ветви:
  • разрешения на чтение и запись для разработчиков, принимающих участие в работе над исправлениями;
  • всем остальным - разрешения только на чтение.
• Частота сборок в ветви По мере необходимости.
• Тесты в ветви Прекращаются после выпуска.

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

Дополнительные ресурсы

• Вводный курс по ветвлению и слиянию можно прочитать в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Подробнее о методах ветвления и слияния в Visual Studio 2005 читайте в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

Как при помощи ветвления сократить количество конфликтов между командами?

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

• Development - Контейнер для ветвей команд.
  • Team 1 - ветвь команды.
    • Source.
  • Team 2 - ветвь команды.
    • Source.
• Main - главная ветвь сборки.
  • Source.
• Другие папки ресурсов.

Учитывайте следующие рекомендации по работе с ветвями команд:

• Когда выполнять ветвление Если разные команды работают с одними и теми же файлами или компонентами, создайте ветви для их изоляции друг от друга. Внутри ветвей команд можно создавать ветви компонентов.
• Когда не следует выполнять ветвление Если дерево исходного кода упорядочено по компонентам и вы уверены, что в командах не возникнет критических изменений интерфейса или большого количества конфликтов, вероятно, у вас нет необходимости создавать ветви команд.
• Разрешения на доступ к ветви:
  • разрешения на чтение и запись для разработчиков из данной команды;
  • всем остальным - разрешения только на чтение.
• Частота сборок в ветви Непрерывная интеграция.
• Тесты в ветви Испытания компонентов и быстрое тестирование качества кода.

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

Дополнительные ресурсы

• Вводный курс по ветвлению и слиянию можно прочитать в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Подробнее о методах ветвления и слияния в Visual Studio 2005 читайте в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

Как при помощи ветвления сократить количество конфликтов в компонентах?

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

• Development - контейнер для ветвей компонентов.
  • Feature A - ветвь компонента.
    • Source.
  • Feature B - ветвь компонента.
    • Source.
  • Feature C - ветвь компонента.
    • Source.
• Main - главная ветвь сборки.
  • Source.
  • Другие папки ресурсов.

Учитывайте следующие рекомендации по работе с ветвями компонентов:

• Когда выполнять ветвление Команды, занятые разработкой компонентов, часто работают с перекрывающимися файлами исходного кода, провоцируя ошибки сборки и конфликты при возврате после правки. Если у вас возникают подобные проблемы, рассмотрите возможность ветвления по компонентам, чтобы изолировать их разработку. Ветвление можно выполнить как в папке Main, так и в папках команд.
• Когда не следует выполнять ветвление Если вы используете только непрерывную интеграцию, при этом ежедневные сборки достаточно стабильны, вам, возможно, нет смысла нести дополнительные расходы, связанные с ветвями компонентов.
• Разрешения на доступ к ветви:
  • разрешения на чтение и запись для разработчиков, работающих над данным компонентов;
  • всем остальным - разрешения только на чтение.
• Частота сборок в ветви Непрерывная интеграция.
• Тесты в ветви Испытания компонентов и быстрое тестирование качества кода.

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

Дополнительные ресурсы

• Вводный курс по ветвлению и слиянию можно прочитать в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library /ms181428(VS.80).aspx.
• Подробнее о методах ветвления и слияния в Visual Studio 2005 читайте в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

Как наиболее эффективно провести ветвление и слияние?

Выполняя ветвление, руководствуйтесь следующими рекомендациями:

• Структурируйте деревья ветвей так, чтобы последующие слияния выполнялись вдоль иерархии (вверх и вниз по дереву ветви), а не поперек. Ветвление поперек иерархии требует последующего слияния без основы, при котором большее количество конфликтов придется разрешать вручную.
• Иерархия ветвей основана родительских и дочерних ветвях и может отличаться от физической структуры исходного кода на диске. Планируя слияния, опирайтесь на логическую, а не на физическую структуру ветвей.
• Не выполняйте ветвление слишком глубоко - это приводит к задержкам при слиянии. Глубокая структура ветвей может привести к тому, что для распространения изменений из дочерней ветви в главную ветвь потребуется много времени. Все это негативно сказывается на графике выполнения проекта и увеличивает время, затрачиваемое на исправление ошибок.
• Выполняйте ветвление на высоком уровне. Включайте в него файлы конфигурации и исходного кода.
• Развивайте структуру ветвей согласно меняющимся нуждам.
• Не выполняйте ветвление, если команде разработчиков не требуется параллельно работать над одним и тем же набором файлов. Если сомневаетесь, для начала пометьте сборку, чтобы позднее при необходимости создать из нее ветвь. Слияние ветвей - затратная операция, особенно, когда между ветвями существуют серьезные отличия.
• Для выполнения слияния и устранения конфликтов требуется один или несколько разработчиков. Полученный в результате код должен быть тщательно протестирован, ибо нередко слияние выполняется некорректно и дестабилизирует сборку.
• Особую сложность представляет слияние поперек иерархии ветвей. Оно требует ручного разрешения многих конфликтов, которые при других обстоятельствах могли бы быть разрешены автоматически.

Дополнительные ресурсы

• Вводный курс по ветвлению и слиянию можно прочитать в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx.
• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Подробнее о методах ветвления и слияния в Visual Studio 2005 читайте в статье "Branching and Merging Team Foundation Source Control" по адресу http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx.

В чем разница между ветвлением и метками?

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

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

Дополнительные ресурсы

• Дополнительную информацию о команде branch вы найдете в статье "Branch Command" по адресу http://msdn2.microsoft.com/en-us/library/ d73s8b27(VS.80).aspx.
• Дополнительную информацию о команде label вы найдете в статье "Label Command" по адресу http://msdn2.microsoft.com/en-us/library/9ew32kd1 (VS.80).aspx.

Что представляет собой модель ветвления в пространстве путей?

Ветви TFS создаются на базе путей хранилища, напоминая операцию копирования файлов. Этим они отличаются от механизма "pin-and-share", используемого в Visual SourceSafe. Подход на базе пространства путей облегчает сопровождение старых версий ПО, поскольку упрощает перенос изменений из одной ветви в другую или внесение изменений сразу в обе ветви.

При ветвлении TFS не создает отдельные копии содержимого файла, поэтому само ветвление не требует значительного дополнительного пространства в БД системы управления исходным кодом. Ветвь содержит указатель в БД на исходный код и список отличий текущего содержимого от базовой версии.

Дополнительные ресурсы

• Вводный курс по ветвлению и слиянию можно прочитать в статье "Branching and Merging Primer" по адресу http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx

Что такое модель распространения TFS?

Моделью распространения ( promotion model ) называется способ передачи изменения из одной ветви в другую. Система Visual SourceSafe также позволяла выполнять ветвление и слияние, но на практике клиенты использовали в качестве простейшего средства распространения механизм "pin-and-share". В TFS изменения распространяются путем слияния файлов из разных ветвей.

Дополнительные ресурсы

• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181425(VS.80).aspx.
• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library /ms181428(VS.80).aspx.
• Подробнее о различиях между Visual SourceSafe и Team Foundation Server Version Control читайте в статье "Visual Source Safe vs. Team Foundation Server" по адресу http://msmvps.com/blogs/vstsblog/archive/2005/07/02/ 56401.aspx.