TFS/Source Control: Как управлять исправлениями

Question

Я пытаюсь понять правильный подход для управления исправлениями с помощью TFS/source-control.

Скажем, у меня есть небольшой проект, содержащий только два файла (app.js и util.js). Оба файла находятся под контролем источника (Team Foundation Server).

Предполагая, что я применил две недели назад метку, обозначающую «веху-1», которая была развернута на сервере. С тех пор я применил несколько других модификаций (расширенный app.js и добавил другие файлы).

Сегодня я нашел ошибку, поэтому я получил версию с меткой «веха-1» с сервера, изменил util.js и развернул эту версию на сервере. Цель состоит в том, что на сервере развернута только версия «веха-1», включая исправление-1, но не изменения, которые я применял последние две недели.

Вопрос: Как/где я могу установить исправление для TFS? Потому что завтра я могу найти другую ошибку, поэтому мне нужно получить версию «веха-1» и базовую базу исправлений 1 для использования второго исправления.

Есть ли способ проверить версию моего кода в TFS, который «сидит» между меткой «milestone-1» и моей последней версией?

Answer 1

С разветвлением и слиянием!

Мы имеем следующий цикл разработки:

1. Первоначальный проект создан, разрешения назначенные, и импортный, чтобы TFS под названием отраслевома «Main».
2. Поскольку это начальная итерация разработки, мы отделяем «Dev» от основного, и именно там работают разработчики. Обратите внимание, что официального релиза нет.
3. Когда разработка завершена, она объединяется обратно в Main. Никакая работа Дева не происходит в Главном филиале.
4. Мы разделяем «Release» от основного, и это тот момент, когда код действительно развернут, а номера версий обновляются.

ОК, поэтому, далее по линии, мы должны внести некоторые поправки. Опять же, «Главная» снова разветвляется, и работа над разработкой продолжается по ветке Dev. Все хорошо. Затем пользователь сообщает об ошибке, которая нуждается в исправлении, и требует быстрой фиксации. Но мы на полпути через наше другое развитие! Что делать?

На этом этапе мы снова отворачиваемся от основного. Назовем это «HotFix». Исправлена ​​ошибка, и затем HotFix объединяется обратно в main. Затем мы можем объединить его в нашу ветку выпуска, и обновление будет отправлено. Наша текущая работа разработчиков не прерывается, и ни одна из работ, которые мы делали до сих пор, не существует на Main).

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

Answer 2

Вы должны использовать ветвление. Ознакомьтесь с руководством «Рейнджерс».

Я успешно использовал план расширенного филиала в прошлом, но вы можете настроить его в соответствии с вашими потребностями. Вы должны быть дисциплинированы с ветвлением, слиянием, проверкой и т. Д. Также рассмотрите полки для изменений кода, которые еще не готовы к передаче даже в ветку DEV.

http://vsarbranchingguide.codeplex.com/

Позвольте мне знать, если вы хотите получить больше информации.