Вопрос

Возможно ли слияние с ветвью, которая не является прямым родительским или дочерним элементом в TFS?Я подозреваю, что ответ будет отрицательным, поскольку это то, что я испытал, используя его.Однако, похоже, что в определенное время это было бы действительно полезно, когда работают над разными функциями, которые могут иметь разные циклы утверждения (т.е.особенность первая мог бы быть одобренным до начала второй функции).Это становится чрезвычайно сложным, когда у нас есть производственные ветки, где мы должны объединить какую-то функцию с предыдущей веткой, чтобы мы могли выпустить ее до выхода следующей полной версии.

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

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

Это было полезно?

Решение

Я согласен с Харпри в том, что вы, возможно, захотите пересмотреть то, как вы настроили свою ветвящуюся структуру.Однако вы, если вы действительно хотите выполнить этот тип слияния, вы можете использовать нечто, называемое необоснованным слиянием.Он запускается из командной строки tfs,

Tf merge /baseless <<source path>> <<target path>> /recursive

Дополнительную информацию о необоснованных слияниях можно найти здесь здесь

Кроме того, я счел этот документ бесценным при построении нашей ветвящейся структуры tfs Руководство по ветвлению Microsoft Team Foundation Server

Другие советы

tf.exe merge /recursive /baseless $/TeamProject/SourceBranch $/TeamProject/TargetBranch

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

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

  • багажник/
  • ответвления/ -/feature1 (отходящие от ствола) -/feature2 (отходящие от ствола)

Если вы сделаете это, то у вас также должна быть возможность объединить feature1 и feature2.

Хотя мой опыт ветвления / слияния с TFS заставляет меня хотеть большего.Я бы хотел, чтобы у нас был только SVN.

Да, вы можете выполнить необоснованное слияние, но только из командной строки (tf.exe).

TFS позволит вам объединяться с ветвью, которая не является родительской / дочерней - это называется необоснованными слияниями.Смотрите эти ссылки:

Из MSDN

От команды TFS через CodePlex

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

Я далек от эксперта по TFS, но я думаю, что вы можете объединить братьев и сестер, и я думаю, что это не безосновательное слияние.

Мы ответвляли нашу основную ветвь (название ветви "main") для функции (название ветви "feature"), затем мне понадобилась часть работы в ветви, которая также была ответвлена от основной ветви (название ветви "dev").Я бы назвал ветви feature и dev братьями и сестрами, поскольку они оба произошли от одного родителя.Я объединил функцию с dev, и все файлы (14000) были помечены как merge, некоторые были помечены как merge,edit.Я не мог отменить (Visual Studio просто зависла бы), поэтому я принял слияние.Затем я объединил dev с main, затем я вытащил main с feature, и снова 14000 файлов были помечены для слияния.Я была действительно расстроена и боялась, что это будет продолжаться.

На этом этапе мы выполнили тестовый проект.Мы настроили main, затем разветвленную разработку и функцию из main.Мы повторили описанные выше шаги с теми же результатами.Как только мы завершили слияние с main на feature, все последующие слияния показывали только отредактированные файлы.

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

Я заметил, что при ветвлении были изменены даты всех файлов.Может быть, в этом и есть проблема?

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top