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

Как выполнить слияние двух ветвей?

Для выполнения слияния можно использовать соответствующую функцию Source Control Explorer или инструмент командной строки merge. Слияние может быть основано на наборе изменений, метке, дате или версии.

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

• Development - контейнер для изолированных ветвей разработки.
  • Feature A
    • Source
  • Feature B
    • Source
• Main - главная ветвь сборки.
  • Source
  • Другие папки ресурсов.
• Releases - контейнер для ветвей выпусков.
  • Release 1.
    • Source.
  • Release 2 - заблокированный текущий выпуск.
    • Source.

Допустим, изменен исходный код в ветви Release 2. В конце рабочего дня вам необходимо выполнить слияние изменений в одну из ветвей компонентов, например, для переноса исправлений в актуальный код компонента. Нелегко будет выполнить слияние напрямую из ветви Release 2 в ветвь Feature B. Вместо этого выполните перенос из Release 2 в ее логическую родительскую ветвь Main, а затем из Main в ее логическую дочернюю ветвь Feature B. Если вам нужно выполнить слияние между ветвями, не имеющими прямых отношений по вертикали, следует произвести слияние без основы.

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

• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library /ms181428(VS.80).aspx.
• Дополнительную информацию о слиянии без основы вы найдете в описании параметра /baseless в статье "Merge Command" по адресу http:// msdn2.microsoft.com/en-us/library/bd6dxhfy(VS.80).aspx.

Можно ли выполнить слияние между командными проектами?

Да, причем, в слиянии между командными проектами нет ничего экзотического. Здесь вполне применимы обычные слияния. Мастер создания командных проектов Team Project Creation Wizard позволяет создать командный проект как ветвь другого проекта.

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

• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx.

Что такое слияние без основы?

Команда branch создает связь между двумя папками, которая используется для выполнения слияний между ветвями. У ветвей, не являющихся прямыми родителями или потомками по отношению к целевой папке слияния, нет такой связи. Согласно определению из MSDN, слияние без основы (baseless merge) представляет собой слияние ветвей в отсутствии базовой версии. Это позволяет производить слияние файлов и папок, не имеющих связей типа "ветвь-слияние". Слияние без основы происходит с гораздо большим количеством конфликтов, чем обычное слияние. Однако после слияния без основы необходимые связи устанавливаются, дальнейшие слияния уже будут иметь основу, и потому количество конфликтов сократится.

Слияния без основы можно выполнить только из командной строки. Даже после проведения первого слияния без основы, когда связи между ветвями уже будут установлены, последующие слияния по-прежнему должны будут выполняться из командной строки.

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

• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/ library/ms181428(VS.80).aspx.
• Дополнительную информацию о слиянии без основы вы найдете в описании параметра /baseless в статье "Merge Command" по адресу http:// msdn2.microsoft.com/en-us/library/bd6dxhfy(VS.80).aspx.

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

Модель продвижения кода ( code promotion ) - это стратегия использования ветвей для продвижения кода по этапам стабилизации. Например, активная разработка осуществляется в ветви Development, в ветви Main производятся сборка и тестирование, ветвь Production используется вашей командой для стабилизации итогового выпуска.

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

• Дополнительную информацию о ветвлении вы найдете в статье "How to: Branch Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx.

В чем отличие между логическим и физическим представлениями ветвей?

Физическое представление - это иерархия построения дерева исходного кода, например:

$/MyTeamProject

• Development.
  • Source.
• Main.
  • Source.
• Releases.
  • Release1.
    • Source.
  • Release2.
    • Source.

Исходный код содержится непосредственно в ветвях Development, Main, Release1 и Release2. Папка Releases содержит несколько ветвей.

Логическое представление - это иерархия родительских и дочерних ветвей в той последовательности, в которой они были созданы, например:

• Main.
  • Development.
  • Release1.
  • Release2.

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

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

• Дополнительную информацию о ветвлении вы найдете в статье "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.
• Дополнительную информацию о слиянии без основы вы найдете в описании параметра / baseless в статье "Merge Command" по адресу http:// msdn2.microsoft.com/en-us/library/bd6dxhfy(VS.80).aspx.

Как часто следует выполнять слияния?

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

• Development - контейнер изолированных ветвей разработки.
  • Feature A.
    • Source.
  • Feature B.
    • Source.
• Main - главная ветвь сборки.
  • Source.
  • Другие папки ресурсов.
• Releases - контейнер для ветвей выпусков.
  • Release 1.
    • Source
  • Release 2 - заблокированный текущий выпуск.
    • Source.

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

1. Как часто команде, занимающейся разработкой компонента, следует переносить изменения из ветви Main в ветвь Feature?
2. Как часто команде, занимающейся разработкой компонента, следует переносить изменения в ветвь Main?

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

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

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

• Дополнительную информацию о слиянии вы найдете в статье "How to: Merge Files and Folders" по адресу http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx.

Возврат после правки и политики возврата

• Что такое набор изменений?
• Что такое политика возврата после правки?
• Как перекрыть политику возврата?
• Как гарантировать соблюдение политики?
• Как пользоваться проверкой возврата после правки?
• Приведет ли к нарушению синхронизации переименование или удаление файлов на диске?
• Как работает система автоматического разрешения конфликтов?
• Как разрешать конфликты вручную?
• Как избежать конфликтов?

Что такое набор изменений?

Набор изменений ( changeset ) представляет собой совокупность всех изменений, связанных с определенной операцией возврата после правки. Все изменения из набора поштучно применяются к TFS во время возврата набора. Наборы изменений обозначаются уникальными последовательно возрастающими номерами.

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

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

• Дополнительную информацию о наборах изменений вы найдете в статье "How to: Retrieve Old Versions of Files from Changesets" по адресу http://msdn2.microsoft.com/en-us/library/ms181416(VS.80).aspx.

Что такое политика возврата кода после правки?

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

По умолчанию в VSTS имеются следующие политики возврата после правки:

• Code Analysis Требует проведения анализа кода перед возвратом.
• Test Policy Требует выполнения определенных тестов перед возвратом.
• Work Items Требует связать с возвратом один или несколько рабочих элементов.

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

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

• О настройке политики возврата читайте в статье "Walkthrough: Customizing Check-in Policies and Notes" по адресу http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx.
• Пример кода с запретом на возврат определенных фрагментов вы найдете в статье "Checkin Policy to Disallow Certain Patterns" по адресу http:// blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx.
• Пример кода с запретом на возврат кода без комментариев вы найдете в статье "Sample Checkin Policy: Make Sure the Comment Isn't Empty" по адресу http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx.
• О том, как зарегистрировать созданную вами политику, читайте в статье "I've Made a New Check-In Policy! How Do I Add It?" по адресу http:// blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx.

Как перекрыть политику возврата?

Для перекрытия политики возврата кода после правки нужно установить флажок Override policy failure and continue check-in. Перекрыть политику возврата может любой член команды, у которого есть разрешение на возврат кода после правки.

Чтобы своевременно узнавать о случаях перекрытия политики членами команды, воспользуйтесь службой событий Team Foundation Eventing Service, чтобы отслеживать события возврата после правки.

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

• Дополнительную информацию о перекрытии политики возврата после правки вы найдете в статье "How to: Override a Check-in Policy" по адресу http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx.
• Дополнительную информацию о службе событий Team Foundation Eventing Service вы найдете в статье "Eventing Service" по адресу http://msdn2. microsoft.com/en-us/library/bb130154(vs.80).aspx.