#tfs #merge #branch #cherry-pick
#tfs #слияние #ветвление #выбор вишни
Вопрос:
У меня есть командный проект в TFS, куда задачи отправляются ежедневно. Я хотел бы работать над каждой задачей независимо, а затем объединить ее в основную строку после тестирования.
В настоящее время существует ОСНОВНАЯ ветвь и ветвь разработчиков, которая является дочерней по отношению к MAIN. Изменения обрабатываются в ветке разработки, а затем объединяются в MAIN, когда они готовы. Это делается с помощью слияния по принципу «вишневого выбора». Я повсюду читал, что слияния по выбору вишни — это плохо, и вам следует избегать их, когда это возможно.
У меня возникли проблемы с тем, чтобы разобраться с ветвлением и слиянием в TFS, и мне было интересно, есть ли у кого-нибудь какие-либо предложения о том, как достичь этой цели в TFS без необходимости выполнять слияния cherry pick.
Приветствуется любая помощь.
Если я пропустил какую-либо ключевую информацию, пожалуйста, оставьте комментарий, и я отредактирую свой пост.
Ответ №1:
Я думаю, что эта документация Codeplex окажет большую помощь:
http://tfsbranchingguideiii.codeplex.com/
Загрузка содержит несколько PDF-файлов, в которых описываются различные сценарии и стратегии и даются отличные вопросы и ответы по различным подходам.
Ключевым моментом для вашего сценария было бы объединить все изменения вплоть до указанной версии из Dev в Main. Запускайте все тесты каждый раз, когда код проверяется в Dev (и разработчики получают последний код Dev, затем запускают все тесты перед регистрацией). В идеале, если сборка в ветке разработки проходит успешно после проверки разработчика, хорошей идеей было бы слияние с Main. Часто выполняйте слияние из Dev в Main и запускайте все тесты в Main после каждой проверки.
Таким образом, даже если разработчики работают индивидуально над определенными частями, как только они регистрируются в ветке разработки, они, по сути, говорят: «этот код готов к интеграции». И при слиянии с Dev на Main вы больше не имеете дело с конкретными частями — вы объединяете всю энчиладу. Если разработчикам нужен контроль исходного кода для незавершенного кода, они должны использовать TFS shelvesets и ждать проверки в Dev, пока они не будут «готовы».
Комментарии:
1. В настоящее время мы ежедневно вносим изменения в DEV. Как только изменение готово к выпуску в рабочую среду, оно объединяется в MAIN. Проблема, с которой я сталкиваюсь, заключается в том, что иногда изменение, которое было зарегистрировано до нового изменения, еще не готово к запуску в производство. Это не позволяет мне выполнить слияние с последней версией и вынуждает меня выполнять слияние по выбору, чтобы я мог выбрать только те изменения, которые готовы к выпуску.
2. Тогда варианты включают в себя: 1) не возвращать код, пока он не будет готов к производству, и нацеливать все изменения на один и тот же производственный выпуск, или 2) измените свою стратегию ветвления так, чтобы у вас было две «незавершенные» ветви — одна для первого выпуска и одна для второго выпуска — которые не сливаются с основной магистралью, пока они не будут готовы к запуску в производство. Последнее звучит как подход, который лучше всего подходит для вашей ситуации.
3. Я могу рассматривать оба способа как решение в этой ситуации, потому что для этого требуются еженедельные выпуски. Способ 1 может быть реализован путем использования наборов полок для хранения изменений, которые еще не готовы, на сервере tfs. Метод 2 может быть достигнут путем создания одной ветви для изменений, которые, скорее всего, будут завершены до следующего выпуска, и другой ветви для изменений, для завершения которых требуется больше времени. Из-за стоимости создания ветвей, я думаю, ваше первое предложение сработает лучше. Спасибо!
Ответ №2:
Возможно, вам покажется интересным инструмент MergeMagician от Timpani Software. Это решение для управления филиалами и автоматического объединения, которое работает с TFS (а также Subversion). Вы создаете отношения публикации / подписки между ветвями, а затем сервер автоматизирует слияния.
MM можно использовать для реализации всех шаблонов, описанных в руководстве по ветвлению TFS, о котором упоминал Шон.
К вашему сведению, это коммерческий инструмент. Я не знаю ни одного инструмента с открытым исходным кодом, который делал бы что-либо подобное, работающего с TFS.
Ознакомьтесь с этим на http://www.timpanisoftware.com . На домашней странице есть хорошее обзорное видео.