TFS /Source Control: как управлять исправлениями
Я пытаюсь понять правильный подход к управлению исправлениями с помощью TFS /source-control.
Скажем, у меня небольшой проект, который содержит только два файла (app.js и util.js). Оба файла находятся под контролем исходного кода (Team Foundation Server).
Предполагая, что я применил две недели назад метку, которая указывает "этап-1", который был развернут на сервере. С тех пор я применил несколько других модификаций (расширенный app.js и добавил другие файлы).
Сегодня я обнаружил ошибку, поэтому я получаю версию с меткой "milestone-1" с сервера, изменяю util.js и развертываю эту версию на сервере. Цель состоит в том, чтобы на сервере была развернута только версия "milestone-1", включая исправление-1, но не модификация, которую я применял последние две недели.
Вопрос: как / где я могу установить исправление в TFS? Потому что завтра я могу найти еще одну ошибку, поэтому мне нужно получить версию "milestone-1" и базовую базу исправлений-1 для применения второго исправления.
Есть ли способ зарегистрировать версию моего кода в TFS, которая "сидит" между меткой "milestone-1" и моей последней версией?
2 ответа
С разветвлением и слиянием!
У нас есть следующий цикл разработки:
- Первоначальный проект создан, права доступа назначены и импортированы в TFS под именем ветви "Main".
- Поскольку это начальная итерация разработки, мы отделяем "Dev" от main, и здесь работают разработчики. Обратите внимание, что на данный момент нет официального релиза.
- Когда разработка завершена, она возвращается в Main. На Главной ветке работа Dev не происходит.
- Мы разветвляем "Release" из main, и это тот момент, когда код фактически развертывается, а номера версий обновляются.
Итак, далее по ходу дела, мы должны внести некоторые поправки. Еще раз, "Main" снова разветвляется, и работа по разработке продолжается вниз по ветке Dev. Все хорошо. Затем пользователь сообщает об ошибке, которая требует исправления и требует быстрого исправления. Но мы на полпути через наше другое развитие!! Что делать?
В этот момент мы снова разветвляемся от основного. Мы назовем это "HotFix". Ошибка исправлена, и затем HotFix объединяется с основной. Затем мы можем объединить его с нашей веткой релиза, и обновление будет отправлено. Наша текущая работа разработчика не прерывается, и ни одна из работ, которые мы выполняли до этого момента, не существует на Main).
Наконец, мы заканчиваем нашу работу по разработке и объединяем ее с основной ветвью, а затем выпускаем. Поскольку наша ветка Hotfix была объединена с основной, наша новая работа по разработке также содержит исправление, которое мы сделали на лету ранее.
Вы должны использовать ветвление. Проверьте руководство "Рейнджерс".
В прошлом я успешно использовал Advanced Branch Plan, но вы можете настроить его под свои нужды. Вы должны быть дисциплинированы с ветвлением, объединением, проверкой и т. Д. Также рассмотрите наборы полок для изменений кода, которые не готовы быть зафиксированными даже в ветке DEV.
http://vsarbranchingguide.codeplex.com/
Дайте мне знать, если вы хотите больше информации.