Я думаю, что вы предлагаете довольно стандартный подход, и просто чтобы убедиться, что я понимаю вопрос, вот сценарий.
Существует ветка Main. Из этой ветки Main были созданы 2 ветки разработки (devA и devB), которые будут использоваться для внесения изменений в код для 2 отдельных проектов.
Разработка в devA достигла стабильного состояния и была объединена с веткой Main. Теперь вы хотите объединить изменения с Main в devB
В devB разработчики вносили изменения в код и проверяли несколько файлов. Вы не хотите, чтобы разработчики регистрировали свои изменения на devB, и вы не хотите инициировать замораживание кода во время перебазирования.
Если разработчики проверяли изменения в devB на регулярной основе с момента создания ветви, вы наверняка увидите конфликты слияния при попытке объединить изменения devA из ветви Main. Кто-то, знакомый с кодом и требованиями для обоих «проектов», должен помочь разрешить эти конфликты слияний. После разрешения конфликтов вы, вероятно, захотите проверить, что код компилируется и что все модульные тесты выполняются и проходят. Если у вас есть ошибки компиляции или не пройдены модульные тесты, то это нужно будет исследовать.
Если вы довольны тем, что слияние с Main до devB было успешным, разработчики с файлами, извлеченными в devB, могут начать проверять изменения. Если извлеченные ими файлы не были изменены в результате слияния с Main, то файлы будут возвращены в обычном режиме. Однако, если у них есть извлеченные файлы, которые были обновлены как часть слияния, TFS запустит инструмент разрешения конфликтов слияния, и разработчикам нужно будет разрешить любые конфликты, прежде чем они смогут проверить код.
Надеюсь, вышесказанное разумно близко к процессу, которому вы сейчас следуете? Если я что-то пропустил или полностью упустил вопрос, дайте мне знать.
Это не так хорошо, как могло бы быть, но это общий подход, который мы используем.
Риск этого подхода заключается в том, что вы можете потратить много времени на устранение конфликтов слияния, особенно если у вас большая кодовая база, в которой множество разработчиков изменяют код во многих ветвях.
Чтобы смягчить любые проблемы, лучше перебазировать как можно раньше и как можно чаще. Рано, потому что если вы сохраните все до конца проекта devA's, изменения могут оказать существенное влияние на devB. Часто потому, что количество конфликтов на объединение сводится к минимуму, что делает разрешение конфликтов проще и менее подвержено ошибкам.
Настройка сборки с "непрерывной интеграцией" также поможет, так как вы столкнетесь с проблемами компиляции раньше, чем позже. Если вы используете TFS 2010, то также может помочь Gated Checking.
Я не уверен на 100%, что это отвечает на ваш вопрос, поэтому дайте мне знать, если я что-то пропустил