TFS Как работает слияние?

Question

У меня есть ветвь релиза (RB, начиная с C5) и набор изменений на trunk (C10), который я теперь хочу объединить с RB.

Файл имеет изменения в C3 (общие для обоих), один в CS 7 на RB, один в C9 (транк) и один в C10).Таким образом, история для моего измененного файла выглядит следующим образом:

    RB:       C5 -> C7
Trunk: C3 ->             C9 -> C10

Когда я сливаю C10 из транка в RB, я ожидаю увидеть окно слияния, показывающее мне C10 | C3 | C7, так как C3 является ревизией общего предкаи C10 и C7 - подсказки моих двух ветвей соответственно.Тем не менее, мой инструмент слияния показывает мне C10 | C9 | C7.

Мой инструмент слияния настроен для показа %1(OriginalFile)|%3(BaseFile)|%2(Modified File), так что это говорит о том, что TFS выбрала C9 в качестве базовой ревизии.

Это совершенно неожиданно и полностью противоречит тому, как я привыкобъединяет работу в Mercurial или Git.Я что-то не так понял или TFS пытается свести меня с ума слиянием?

Это стандартное поведение TFS Merge?Если да, можете ли вы объяснить, почему они решили реализовать его таким образом?

Я использую TFS 2008 с VS2010 в качестве клиента.

Answer 1

У меня были некоторые похожие начальные проблемы с ветвлением и слиянием TFS (у нас есть dev, интеграция и основные ветки).

Короткая версия заключается в том, что вы не можете слиться непосредственно из наконечника с общим предком.

Таким образом, если C3 был разветвлен до C5, то C7 был разветвлен до C9, то, что предоставляет инструмент, имеет смысл в контексте того, как работает TFS. По сути, вам нужно перейти от C10 / C9 к C7, а затем от C7 к C3.

Другими словами, вот как мы работаем с многоуровневым ветвлением и слиянием в наших проектах.

Начнем с магистрали / магистрали.

Затем мы перейдем к ветви интеграции.

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

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

Как только интеграция проходит QA, мы затем реверсируем интеграцию, объединяя транк и интеграцию (на случай, если в main есть какие-либо исправления), а затем интегрируем все объединенные изменения в интеграции вплоть до main.

В день выпуска мы делаем одну последнюю ветвь от основной в новую ветку выпуска, которую мы затем развертываем.

По сути, в TFS вам всегда нужно идти вверх и вниз по дереву ветвления / слияния от ствола к ветке к ветке к листу - вы не можете в любой момент обойти ни один шаг в иерархии ветвей.

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

Требуется немного привыкнуть, но однажды сделанный (и особенно когда вы привыкли к парадигме прямой интеграции / обратной интеграции), он приносит удовольствие, особенно когда у вас есть несколько человек, которые все занимаются разработкой, и вам нужно обернуть все изменения, не запутавшись.

Надеюсь, это поможет!

Answer 2

Я думаю, что у вас может неправильная методология слияния, потому что то, что вы описываете, вполне возможно, и это работает для меня. Но вы всегда должны помнить, что когда вы начинаете ветвление, основной ветвью является правильная RI (обратная интеграция) и FI (прямая интеграция). Ищите в codeplex руководящие принципы и лучшие методы ветвления .

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

Answer 3

Я просматривал этот сайт раньше и наткнулся на эту страницу, это полезно?

Как разветвляться и объединяться в TFS