Препятствия для использования Git Flow в Subversion


10

Моя команда на работе начинает новый проект, используя Subversion в качестве нашей VCS (вы можете рассмотреть этот набор в камне для целей этого вопроса). Мы все еще находимся на ранних стадиях проекта и пытаемся согласовать модель ветвления. Наш предыдущий проект был основан на нестандартной модели версий, которая приводила к проблемам при управлении оперативными исправлениями и исправлениями для существующих выпусков.

Я обнаружил, что различные модели ветвления довольно сложны, но одна модель, которую я достаточно четко понимаю, это git flow . Мне любопытно, насколько сложно / нежелательно было бы реализовать эту вариацию в Subversion. Очевидно, что есть некоторая разница с точки зрения людей, сотрудничающих в филиалах. Ветви функций должны быть централизованы, а не ограничены локальными репозиториями, но другие концепции модели должны воспроизводиться в Subversion, насколько я понимаю.

Какие бы были недостатки или проблемы у этого подхода. Что я слышал, так это то, что в SVN «слияние дорого» по сравнению с Git. Но я не совсем понимаю, что это означает на практике или как это повлияет на нашу способность использовать Git-поток, такой как модель ветвления.

Что будет самым большим беспокойством с этим подходом. Есть ли такой же ясный подход, который более естественен в Subversion?

Ответы:


12

Gitflow основан на лучших практиках управления версиями и ветвлениями исходного кода. Очень хорошая статья об этом - Advanced SCM Branching Strategies

Смысл, который Вэнс делает в связанной статье, состоит в том, что разные ветви играют разные роли . Он определяет роли:

  1. Главная линия (все филиалы отсюда)
  2. Разработка (где ведется разработка)
  3. Техническое обслуживание (где выполняются работы по техническому обслуживанию)
  4. Накопление (объединение вещей в подготовке к выпуску)
  5. Упаковка (упаковка для выпуска)

В gitflow это:

  1. развивать
  2. тематические ветви
  3. Ветки исправлений
  4. Выпуск веток
  5. Мастер

Статья о ветвлении была написана с учетом Perforce. Perforce - это централизованный VCS, очень похожий на svn. Шаблоны ветвления, которые он описывает, идеально соответствуют svn.

Ключ к пониманию заключается в том, что не то, как gitflow переносится на svn, а как применять те же фундаментальные концепции ветвления и роли ветвей к различным структурам VCS.

Я настоятельно рекомендую прочитать статью, я не могу сделать много кредитов для этого. То, как все описано, основано на философии сборки магистрали / магистрали, которую вы легко сопоставите с SVN.


1
Возвращаясь к идеям, лежащим в основе разработки gitflow, это умное улучшение оригинального вопроса!
user40989 12.12.13

@ user40989 Я не уверен, что Винсент Дриссен (nvie) прочитал статью или нет, которая выдвинула эту концепцию ветвления, или он открыл это самостоятельно. В любом случае, признание того, какие роли необходимы для рабочего процесса через управление версиями, позволяет легко увидеть сходство между подходами и лучшими практиками.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.