Каковы некоторые рекомендации для поддержки нескольких версий проекта?

Question

У меня есть проект, в котором мы запускаем v1 и начинаем работу над v2. Я боюсь, что в ближайшие несколько месяцев мы увидим исправления ошибок и незначительные изменения функций v1, некоторые из которых нам нужно будет перейти на v2, некоторые из которых нам нужно сохранить отдельный. (Нам нужно поддерживать основной набор функций v1, но исправлять ошибки по мере их обнаружения.)

Мы сейчас используем SVN. Я подумывал о переходе на Git, но я немного не хочу менять инструменты. Помимо этой возможности, каковы некоторые общие стратегии и передовые практики, позволяющие максимально упростить управление этой ситуацией?

Обновление: все предлагают, чтобы я ветвил код в Subversion. Это было настолько очевидно для меня, что я подумал, что это подразумевается под выражением «мы используем SVN». Очевидно нет. :) Я собираюсь посмотреть на Mercurial и Bazaar, а также на Git. Что-нибудь еще?

Answer 1

Используя SVN, лучшее, что вы можете сделать, это ветвить свой репозиторий:

• В багажнике держите последнюю версию - не обязательно стабильную.
• Всякий раз, когда вам нужно отделить новую основную версию оттуда, переходите, скажем, на 2.0, и вы можете хранить и последнюю версию, и стабильные версии в одном репо.
• Если вы обнаружите изменения в ветке 2.0, которые необходимо объединить в транк, вы можете сделать это без проблем.

Answer 2

мы используем TFS, но для вашей конкретной проблемы решение будет очень похожим: создайте новую ветку.
[В зависимости от среды приложения, которую вы используете, очевидно, не Microsoft]
Мы получили пользу от TFS, потому что:

1. Вы можете делать слияния между ветвями [необоснованные слияния]
2. Вы можете работать с рабочими элементами, [для отслеживания ошибок]
3. С поддержкой sharepoint у вас могут быть документы, тестовые сценарии могут счастливо жить вместе на одном портале.
4. С помощью сценариев PowerShell вы можете иметь ночные автоматические слияния

Answer 3

Для разных версий рекомендуется хранить именованные версии в подпапке «tags». (Документация SVN рекомендует иметь папку с стволом, тегами и ветвями для каждого проекта).

Всякий раз, когда вы выпускаете версию, копируйте ствол в папку тегов и присваивайте ему имя. Эта версия может существовать, и исправления ошибок могут быть внесены в нее отдельно и объединены назад и вперед.

Документы SVN по макету хранилища:

http://svnbook.red -bean.com / ен / 1.2 / svn.branchmerge.maint.html

Answer 4

Используя git , вы можете использовать следующий подход:

В вашем репозитории git могут быть следующие ветки. Каждая ветвь исправлений содержит выпуск функций, который необходимо поддерживать.

master                  - version: 3.0.0 (latest release)
  \ 
  dev                   - version: 4.0.0 (next release)
  |\
  | hotfix-1.x          - version: 1.0.1 (current hotfix 1.x)
  \
  | hotfix-2.x          - version: 2.0.1 (current hotfix 2.x)
  \
    hotfix-3.x          - version: 3.0.1 (current hotfix 3.x)

Исправления:

Исправления сделаны в hotfix-1.x и объединены «вверх» в hotfix-2.x и оттуда в hotfix-3.x.

hotfix-1.x -> hotfix-2.x -> hotfix-3.x ...

Исправления также могут быть перенесены с помощью команды git cherry-pick из hotfix-3.x в hotfix-1.x (при необходимости). С помощью команды cherry-pick можно выбрать один коммит и применить его в другой ветке. Git также будет обнаруживать перемещенные и переименованные файлы и по-прежнему корректно применять изменения.

Вы также можете добавить ветки релизов параллельно ветвям исправлений, чтобы подготовить выпуски в этих ветвях (опущено для этого примера). Это полезно, когда вы не хотите блокировать ветви исправлений для новых коммитов. Пожалуйста, проверьте gitflow , если вы хотите узнать больше о деталях исправлений и веток релиза.

Релизы функций:

Новые функции основаны на ветке dev и объединены обратно в ветку dev после завершения. Новая ветвь исправлений создается для каждого выпуска новой функции.

Шаги:

• Объединить изменения из текущей ветви исправлений в dev
• Слияние ветвей объектов обратно в dev
• Создать новую ветку исправлений из dev
• Релиз от новое исправление ветка
• Слияние с мастером

Примечания:

Я думаю, что основная ветвь больше не очень важна, когда вы решаете оставить свои ветки исправлений. Я полагаю, что общая схема gitflow работает таким образом, что вы удаляете свои ветви исправлений и выпускаете ветви, как только закончите. Все ваши релизы должны быть помечены и поэтому доступны.

Answer 5

Рассматривали ли вы ветвление своего ствола и разработку v2 на второй ветке, когда ветка v1 заморожена? Если вы исправляете ошибки в ветви v2, которые влияют на v1, и вы хотите выпустить обновление / патч для v1, просто объедините эти конкретные изменения с веткой v1 из ветви v2.

Все это прекрасно выполнимо в SVN, но гораздо проще осуществлять управление ветвями с помощью таких инструментов, как Mercurial или Git. Я не могу сказать вам, стоит ли переходить на него или нет, поскольку я не знаю вашу компанию или кодовую базу, но стоит подумать, сможете ли вы предвидеть эту ситуацию, возникающую неоднократно в будущем по мере выпуска новых версий.

Answer 6

Вы должны использовать SVN, чтобы пометить код v1. Таким образом, вы можете создать отдельную ветвь кода для поддержки исправлений в этой кодовой базе.