Руководства

Чаще выполняйте слияния

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

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

• Development - папка для изолированных ветвей разработки.
  • External - ветвь внешней зависимости.
  • Team 1 - ветвь команды.
  • Team 2 - ветвь команды.
    • Feature A - ветвь функции.
    • Feature B - ветвь функции.
    • Feature C - ветвь функции
• Main - ветвь интеграции.
• Releases - папка для ветвей выпуска.
  • Release 2 - ветвь выпуска.
• Safe Keeping - папка для хранения архивных копий ветвей.
  • Release 1 - архивная ветвь.

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "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.

Всегда создавайте папку верхнего уровня для нового командного проекта

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

Далее показан пример типичной структуры ветвления:

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

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "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.

Используйте перед слиянием параметры Candidate или Preview

Перед выполнением слияния используйте параметры \candidate или \pre-view, чтобы проверить результаты слияния. Хотя эта возможность доступна только из командной строки, пренебрегать ею не следует. Она позволяет узнать, слияние каких файлов и версий будет выполнено при запуске команды слияния. С ее помощью, например, можно удостовериться, что реальный масштаб слияния не превышает ваши ожидания и что вы правильно оценили все последствия предпринимаемого слияния. При выполнении больших слияний отчет о слиянии поможет вам разделить работу между разработчиками или группами.

Для предварительного просмотра результатов слияния запустите инструмент командной строки Tf.exe с командой merge и параметрами preview или candidate, например:

Tf merge main/source development/feature/source /preview

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

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "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.

Если в составе слияния выполняется переименование, обращайте внимание на предлагаемый системой путь

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

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "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.

Соблюдайте осторожность при разрешении конфликтов слияния

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

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

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

• Дополнительную информацию о разрешении конфликтов слияний вы найдете в статье "Resolving Conflicts" на сайте MSDN по адресу http://msdn2.microsoft.com/en-us/library/ms181432(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.

Проводите тесты после слияния, но перед возвратом

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

Изначально результаты слияния изолированы в вашей рабочей области и не выгружаются на сервер, пока вы не вернете отложенные изменения.

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

• Вводный курс по ветвлению и слиянию вы найдете в статье "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.

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

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

Возвращайте код, только убедившись в его надежности

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

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

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

• Дополнительную информацию о возврате после правки вы найдете в статье "How to: Check In Pending Changes" по адресу http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx.

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

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

Чтобы отложить правки, сначала просмотрите их список: щелкните правой кнопкой решение в окне обозревателя Solution Explorer и выберите команду View Pending Changes. Выберите файлы, которые хотите отложить и щелкните Shelve. Введите имя набора и комментарий, поясняющий его назначение, а затем щелкните Shelve.

Извлечение набора отложенных правок

1. Откройте меню File, разверните подменю Source Control и выберите команду Unshelve.
2. В поле Owner name введите имя создателя набора отложенных правок (например, Contoso\JimB или просто JimB ) и щелкните Find.
3. В области Results выберите набор отложенных правок, который хотите загрузить в рабочую область и щелкните Details.
4. Чтобы удалить набор отложенных правок после его извлечения с сервера управления исходным кодом TFS, сбросьте флажок Preserve shelveset on server. Система TFS восстановит каждую отложенную правку в целевую рабочую область в качестве незавершенного изменения, при условии что правка не конфликтует с уже существующим отложенным изменением в этой же рабочей области.
5. При необходимости сбросьте флажок Restore work items and check-in notes, если не хотите загружать рабочие элементы и заметки о возврате восстанавливаемого набора. В открывшемся диалоговом окне Details выберите наборы отложенных правок или их элементы, которые хотите поместить в рабочую область, и щелкните Unshelve.

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

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

Разрешайте только один рабочий элемент за один возврат

После разрешения рабочего элемента верните отложенные изменения и обновите статус рабочего элемента. Суть выполнения данной процедуры в следующем:

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

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

• Дополнительные сведения о возврате после правки вы найдете в статье "How to: Check In Pending Changes" по адресу http://msdn2.microsoft. com/en-us/library/ms181411(VS.80).aspx
• Дополнительную информацию о рабочих элементах и наборах изменений вы найдете в статье "How to: Associate Work Items with Changesets" по адресу http://msdn2.microsoft.com/en-us/library/ms181410(VS.80).aspx.
• Подробнее об анализе сведений о рабочем элементе читайте в статье "How to: View Work Item Details from Pending Changes Window" по адресу http://msdn2.microsoft.com/en-us/library/ms245467(VS.80).aspx.

Применяйте политики возврата для соблюдения стандартов программирования

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

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

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

1. В окне Team Explorer щелкните правой кнопкой нужный командный проект, раскройте подменю Team Project Settings и выберите команду Source Control.
2. Перейдите на вкладку Check-in Policy и щелкните Add.
3. В диалоговом окне Check-in Policy установите параметр Code Analysis и щелкните OK.
4. В окне Code Analysis Policy Editor установите Enforce C/C++ Code Analysis (/analyze) или Enforce Code Analysis for Managed Code. Установите оба параметра, если проект содержит как управляемый, так и неуправляемый код.
5. Если вы выбрали параметр Enforce Code Analysis for Managed Code, настройте правила анализа управляемого кода в соответствии с вашими стандартами программирования.

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

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

• Дополнительную информацию о создании пользовательской политики возврата вы найдете в разделе "Как создать собственную политику возврата TFS " этой книги.
• О настройке политики возврата читайте в статье "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.