TFS Branching - 2 ветки разработки

Question

TFS Branching - 2 ветки разработки

1

В настоящее время я использую TFS и имею следующую структуру.

Линия Dev, линия Mainline и Release в моей иерархии TFS. Я использую тот же подход, что и в приведенной ниже ссылке:

http://blog.tfsserver.com/a-straightforward-guide-to-branching/

(Я планирую сохранить 2 или 3 последних выпуска в выпуске)

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

В настоящее время в моей линии dev у меня есть ветвь dev, которая была создана из mainline.

Эта ветвь exsiting dev в настоящее время разрабатывается разработчиком, где изменения будут готовы через 4 недели.

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

Имея это в виду, я, очевидно, не хочу использовать существующую ветвь dev.

Я не могу внести изменения непосредственно на магистрали, поэтому мне интересно, подходит ли следующий подход, который я рассматриваю, правильный подход?

Я думаю, мне нужно:

(1) Создайте ветку NEW Dev с главной линии. Тогда у меня была бы моя оригинальная/существующая ветвь dev и теперь новая ветвь dev. Оба они были бы разветвлены из-за того же исходного кода.

(2) Внесите изменения в ветку NEW dev

(3) Как только я доволен своими изменениями, я затем объединил свои изменения с Mainline и выпустил изменения в производство (или выбранные клиенты) и объединил свои изменения с исходной ветвью Dev. Затем, когда первоначальные изменения ветки dev завершаются через 2 недели после моего, они будут объединены с основной линией.

Мне интересно, это правильный подход? Могу ли я объединить изменения из ветки NEW в существующую ветвь dev, даже если я не создал свою новую ветку из существующей ветки dev?

благодаря

Kev 29 июнь 2014, в 01:21

Источник

Теги:

c#

visual-studio

tfs

branching-and-merging

source-control-explorer

2 ответа

2

Вы можете рассмотреть следующую методологию.

Состав

Главный

Содержит основное исходное дерево. Самые последние разработки.

Контрольная работа

Разветвлено от Main и используется для изоляции тестирования.

развитие

Разветвленный от Майн и используемый для изоляции активного развития.

производство

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

Обслуживание

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

Безопасно

Эта папка содержит ветки, которые вы больше не поддерживаете. Когда выпуск больше не подходит для обновлений, вы перемещаете его из контейнера Maintenance в контейнер Safe.

Этапы

поток

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

Когда сборки из ветки разработки стабильны и готовы к тестированию, команды объединяют ветвь разработки в ветку тестирования.

Когда QA принимает сборки, команда объединяет тестовую ветку в главный филиал и создает производственный филиал из Главного ветки и позволяет внешним пилотным пользователям использовать его.

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

Если релиз больше не принимает обслуживание, команда перемещает ветку из контейнера Maintenance to Safe.

ПЕРЕД НАЧАЛОМ РАБОТЫ на ветких в контейнере обслуживания ВСЕГДА убедитесь, что вы выбрали его.

Взято из ветвления и слияния TFS

cilerler 28 июнь 2014, в 20:52

Ещё вопросы

Erik Funkenbusch · Accepted Answer · 2014-06-28T20-28-00.000Z

Если вы введете ветку из ветки выпуска, вы можете объединить эти изменения, независимо от каких-либо других ветвей. Они тоже могут объединить свои изменения, но им, возможно, придется пройти этап разрешения конфликтов слиянием, если вы оба работали над одним и тем же файлом.

Когда вы объединяете свои изменения в Mainline, ветвь dev может объединить изменения с Mainline в свой код.

Еще один вариант, если вы еще не хотите проверять изменения в mainline... если вы используете новейшую версию Visual Studio и TFS, вы можете использовать полки для объединения кода между ветвями. Тем не менее, только последние версии VS/TFS делают Shelveset сливается с Unshelving. Раньше он просто копировал любую версию файла, которая была отложена на все изменения, которые вы могли бы сделать.

Привет, Эрик, спасибо за это. Итак, насколько я понимаю, нет риска потери изменений из исходной ветви или риска перезаписи изменений из более новой ветви dev, пока я выполняю правильные операции слияния между ветвями. Шаги по разрешению конфликта слияния позволят мне получить последнюю версию и объединить первоначальные изменения dev с mainline. Я отмечаю ваш ответ как мой принятый ответ :)