Вы можете вручную извлекать код из каждой ветви, вносить изменения впоследствии в каждую ветку и регистрироваться. Очень осторожно .
Намного лучше , если эти 3 окружения будут ветвями друг друга. (Обычно вы начинаете с dev и переходите к другим 2 по очереди). Затем вы можете использовать функциональность Merge для объединения (например) ваших наборов изменений dev непосредственно для тестирования и т. Д. В этот момент ваши тестовые модули (которые должны быть изменены для соответствия dev) извлечены с изменения. Затем просто внесите изменения. Затем повторите для постановки и промыть. Это предложенная методология для этого общего сценария.
Два важных примечания:
- Несмотря на то, что TFS, если он сильно ориентирован на сервер (по сравнению, например, с SVN), эта функциональность объединения происходит на клиенте. Вам необходимо сопоставить каждую ветку с вашей машиной. После завершения процесса слияния вы не будете вносить изменения в целевую ветку, пока не зарегистрируетесь.
- В видении Microsoft и в приведенном мной примере эти ветви являются постоянными. Это было изменение по сравнению с моей предыдущей практикой использования SVN, где целые ветви были созданы / продвинуты / удалены все время. Таким образом, вы создаете ветку Test , и она остается на неопределенное время веткой Test . Это никогда не продвигается; его изменения объединены в другом месте.
Строительство - это отдельное действие. Вам необходимо настроить отдельную сборку для каждой ситуации, хотя, разумеется, как только вы настроите первую, две другие будут тривиальными. После слияния с staging вы запустите этап build . (Из Team Explorer или в меню Build). TFS немного тяжел, но после настройки он очень хорошо справляется с этой ситуацией, и распределенная команда может легко объединяться и собираться (с помощью автоматических тестов сборки и т. Д.).