Как сохранить исходные версии и древовидную структуру проекта в репозитории исходного кода - PullRequest
Новая
       0

Как сохранить исходные версии и древовидную структуру проекта в репозитории исходного кода

1 голос
/ 30 июля 2010

Для команды из 4-5 разработчиков, использующих Visual Source Safe (VSS) 2005, как лучше поддерживать исходные версии?

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

-trunk - Основное решение и проект
-Dev филиалы - филиал, созданный для разработки и улучшения 

-Dev (some enhancement)

-Release - выпуск веток 

-Release 2.1.0  
-Release 2.1.1  
-Release 3.0

Все, что начинается с тире (-) выше, является папкой в ​​хранилище.

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

После того, как проект (в данном случае веб-приложение) развернут и подтвердил, что он стабилен, мы делаем ветку Release (version #) ветки Dev выше. Допустим, это версия 3.0, теперь мы знаем, что в июле 2010 года мы поместили код в папку версии 3.0.

Затем мы объединяем (это легко в VSS2005) код Выпуска 3.0 со стволом. Таким образом, транк всегда является последним развернутым кодом, и следующее усовершенствование будет ветвиться от транка.

HotFix

Некоторые вещи, которые я еще не выяснил, это то, что происходит, когда существует ветка Dev, над которой ведется работа, и существует оперативное исправление, которое необходимо немедленно развернуть.
Возможно, мы делаем отдельную ветку из последней папки Release, называем ее Hot-fix 3.0. Попросите разработчиков внести исправление, объединить его с кодом Выпуска 3.0 после развертывания исправления, а затем снова объединить с транком.

Очистить

После релиза действительно нет необходимости иметь ветки dev. Должны ли они быть удалены?

Поскольку мы выполняем ветвление, я прочитал, что удаление ветки в VSS не освобождает пространство в базе данных, пока не будет удален оригинал.

Как мы должны удалить или мы должны удалить ветви dev?

Это мои мысли, как вы управляете своими версиями и каковы ваши рекомендации для моих требований.

Мы МОЖЕМ перейти в TFS в будущем, поэтому все, что я сейчас реализую в VSS, должно учитывать этот шаг в будущем.

1 Ответ

2 голосов
/ 17 октября 2010
  • trunk -> должен содержать только стабильный код
  • tag -> добавить теги к коду магистрали для идентификации версий (например, выпуски 2.1.0, 2.1.1, 3.0 и т. Д.)
  • ветка -> создать ветку для каждой проблемы
  • update -> часто обновлять ветки, чтобы код был как можно ближе к стволу (потому что другие исправления были зафиксированы)
  • merge -> объединить ветви в магистраль, если решение стабильно (укажите номер проблемы, чтобы изменения кода были связаны с номером проблемы)

Самое важное из всех:

  • использовать систему контроля версий, которая поддерживает вас в этом -> VSS не будет;)

Также взгляните на эту интересную статью: http://betterexplained.com/articles/a-visual-guide-to-version-control/

...