Вопрос: Если «Выпуск B» создан ДО ДО завершения проекта «Разработка», то требуется «Исправление» для «Выпуска А», как мне распространить это «Исправление» из «Выпуска А»в «Релиз B», не забирая какие-либо проекты «Разработки», которые были завершены за это время?
Краткий ответ: Для конкретного описанного сценария, я полагаю, вы могли бы безопасно объединиться сВыпуск A через Main и затем резервное копирование в Выпуск B. (Да, это идентично тому, что Джеффри МакГрат заявил в комментарии 8/16.) Как правило, вы не выполняете никаких слияний FI из Main в выпускную ветвь после созданияветвь, но если вы можете подтвердить, что единственное изменение в Main - это ваше исправление, то объединение должно безопасно выполнить вашу цель. ОДНАКО это основано на очень сомнительном предположении, что у вас есть чистая ветвь Main, и ничто другое не слилось с Main, так как "Обслуживание Выпуска B" было разветвлено.Прежде чем продолжить, очень тщательно проверьте это предположение!
Грязные Основные обходные пути - сбор вишни или необоснованное объединение: Если в Main есть другие изменения, то вы можете выбрать вишню, чтобы объединить конкретное исправление из основного в«Выпуск B Пакет обновления».Другой вариант - выполнить безосновательное слияние из «Обслуживание выпуска A» непосредственно в «Обслуживание выпуска B», которое обходит любые другие изменения в Main.(Вам все еще нужно объединить это исправление через main, чтобы ветки Dev получили исправление.) Обратите внимание, что слияния вишневого пика и необоснованные слияния имеют более высокий риск, чем обычные слияния (которые могут быть достаточно сложными как есть).Тем не менее, они являются допустимыми вариантами для определенных сценариев, где лучшего решения не существует.
Мета-ответ № 1: Я считаю, что рисование диаграммы помогает мне следить за изменениями от первоначальной ветви до конечного пункта назначения.У Cherry-pick нет специальных обозначений, но безосновательное слияние может быть стрелкой с пунктирной линией.Если он работает на бумаге (и вы учли все другие ответвления ветви с Main), то он должен работать.
Мета-ответ № 2: Если выше не ответил прямо на ваш вопрос, тоЯ бы порекомендовал прочитать форум http://tfsbranchingguideiii.codeplex.com/discussions и опубликовать этот конкретный запрос.Билл Хейс, как правило, очень отзывчив на этом форуме, и ваш вопрос определенно указывает на управление исправлениями в ветвлении TFS.
К вашему сведению:
Моя команда работает над несколькими проектами SOA (Service Oriented Architecture), которые сталкиваются с аналогичными проблемами SaaS.Цикл QA на один месяц - сложное осложнение.
Мне очень нравится статья Мартина (достаточно, чтобы привести ее еще раз ниже).Есть две дополнительные статьи, которые стоит рассмотреть (в обеих есть красивые картинки для дополнения хороших диаграмм TFS Branching Guide).Однако все три статьи посвящены управлению ветвями разработки, а не управлению ветвями выпусков исправлений (так же, как в предыдущем ответе).
- Руководство: стратегия ветвления для Scrum-команд - Мартин Хиншелвуд 2010.04.14 - Отличное прохождение базовой стратегии «ветвление за выпуском», так как команда Scrum работает через 2 спринта (сотличные диаграммы).
- Ветвление для Scrum - Билл Хейес (ALM Ranger) 2011.01.18 - Отличные диаграммы команды Scrum и ветви масштабирования.
- Параллельные группы функцийработает над несколькими выпусками в разработке .Ежемесячные выпуски к производству.- Bill Heyes 2011.01.14 - Очень похоже на наш сценарий ветвления (3 команды разработчиков Web + 1 среда разработки).Руководство - Ветвь от Команды + Ветвь от Выпуска.
Наслаждайтесь!- Zephan