Можно ли использовать модель git-flow с Subversion?

мы используем Subversion, и кроме нескольких человек, таких как я, мало опыта ветвления и слияния в Subversion. Мой опыт Subversion ограничен простыми ветвями функций, где слияние и конфликты дерева, хотя и не совсем редки, не очень трудно решить.

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

  1. как мы разрабатываем код параллельно для этого выпуска и последующих выпусков?
  2. какой код считается стабильным?
  3. что (в разработке) код будет в следующем выпуске?
  4. какой (в разработке) код собирается в последующем выпуске?
  5. какая версия кода является нашим тестом, Принятие, или производственные среды?
  6. как мы интегрируем параллельные разработки с известным стабильным выпуском, чтобы уменьшить количество ошибок и неполной работы?
  7. как мы предоставляем горячие исправления для выпущенного кода?
  8. как мы узнаем из нашей системы управления версиями, какая деятельность по разработке в настоящее время продолжается?
  9. как мы экспериментируем или R&D без нарушения текущей базы кода при использовании?

кажется, что git-flow, как определено здесь будет идти долгий путь, чтобы ответить на многие из этих вопросов. Я экспериментировал с этим методом в Mercurial, и кажется, что этот метод можно реализовать и там. К сожалению, миграция на DVCS на данный момент отсутствует.

однако моя краткая попытка имитировать этот метод в Subversion не удалась со многими конфликтами слияния и дерева. Варианты слияния и крайние случаи многочисленны и озадачивают.

может ли Subversion быть используется для реализации git-flow и если да, то каков уровень боли?

32
branching-and-merging git-flow svn trunk

3 ответов

мы используем то, что называется нестабильная метод развития ствола. Это была методология разработки, которую имели в виду создатели Subversion, когда создавали Subversion. Это просто и легко реализовать.

  • вы делаете все свое развитие на багажник. Так называется неустойчивый багажник.
  • когда вы приближаетесь к выпуску, вы делаете ветку для этого выпуска. Идея сделать ветку достаточно поздно держите параллельную разработку как можно короче, но не настолько позже, чтобы некоторые разработчики не могли выполнять свою работу, потому что им больше не нужно работать над текущим выпуском, а нужно начать работать над следующим выпуском. В Agile это обычно делается прямо перед укрепляющая спринт. Обычно это делается, когда Выпуск завершен, и теперь вы просто исправляете ошибки.
  • освобождение происходит от филиала. Ты помечаешь ветку. Если есть патчи, которые нужно, чтобы их сняли с ветки.

вот идея, как это работает:

  • представьте, что вы работаете над выпуском 1.2. Ты работаешь над багажником. Теперь вы приближаетесь к тому времени, когда релиз 1.2 будет выпущен, и в выпуске 1.2 недостаточно работы, чтобы ваши разработчики были заняты. Вы создаете ветку 1.2 для своего выпуска.
  • теперь люди, все еще работающие над выпуском 1.2, переключаются на выпуск 1.2. Между тем, разработчики работают над 1.3 stay on багажник.
  • теперь вы готовы выпустить 1.2. Вы отмечаете выпуск 1.2 прямо на ветке. Ветвь не сливается обратно в ствол. Багажник для версии 1.3.
  • ошибки сообщаются, и вы хотите исправить их в выпуске 1.2.1. Вы продолжаете работать с филиалом 1.2. Нет необходимости в новой ветви для 1.2.1. (Вы можете заблокировать ветви между выпусками, чтобы сохранить их чисто.
  • когда вы собираетесь сделать релиз 1.3, вы повторяете процесс -- ветвь 1.3 и работа для 1.4 продолжается на стволе.

будет некоторое слияние. Это в основном слияние дефектов, зафиксированных на ветке выпуска обратно в багажник. Есть три варианта сделать это:

  • как только вы сделаете выпуск, вы объедините enmass все изменения на ветке обратно в магистраль. Очень мало следов. Вы просто предполагаете, что все исправления ошибок на ветке также применяются к багажнику.
  • вы использовать системы отслеживания, которые понимают проблемы, могут жить на более чем одном выпуске. В этом случае вы просто отмечаете ошибку, обнаруженную на ветке, чтобы багажник тоже. Вы можете черри выбрать изменения, которые применяются к багажнику благодаря вашей системе отслеживания проблем.
  • некоторые сайты просто не сольют. Они также отслеживают через систему отслеживания дефектов изменения, которые необходимо применить к магистрали, которые были применены на ветке, и просто повторно реализовать их. Они могут копировать изменения из ветки в ствол, но они никогда не формального объединения. Однако, как только вы это сделаете, вы никогда не сможете объединиться (если вы не объединитесь с --record-only флаг).

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

вы можете реализуйте стандартный рабочий процесс Git, который использует отдельные ветви разработки для каждого разработчика или проблемы, а затем доставка эти изменения на багажник. Для этого потребуется много филиалов, по одному для каждого разработчика/функции.

вы сначала сливаетесь от ствола к ветви до rebase ваш код. После того как вы сделали перебазирование, ты сливаешься с ветки обратно к стволу с помощью --reintegrate переключатель. Pre-1.6, вы должны были удалить ветвь и воссоздать его с --reintegrate вид испорченного отслеживания слияния. Однако, это было исправлено в версии 1.6.X и выше.

28

это большой вопрос. У меня есть только идеи, как решить некоторые проблемы:

  1. Я не думаю, что это можно легко решить без использования ветвей много. Не уверен, что это можно легко решить с помощью GIT. Ветви функций проходят долгий путь в решении этой проблемы, но в целом вы, вероятно, должны попытаться сосредоточиться на функциях только для следующего выпуска.
  2. trunk - Я считаю, что это master филиала.
  3. Я бы сказал development ветку является ли код для следующего выпуска
  4. кажется сложным без использования большого количества ветвей, не знаю, как правильно это решить.
  5. вы можете использовать ветви или отметить номер ревизии в TEST и ACC. Прод должен быть помещен в тег, я думаю.
  6. Я бы сказал, используя автоматические регрессионные тесты и непрерывную интеграцию. Также использование рецензий может помочь здесь, в лучшем случае вы используете какой-то инструмент, чтобы отметить файл как просмотренный. Таким образом, вы можете убедиться, что вы только сливаетесь файлы, которые были рассмотрены. Также может быть интересно связать Ваши сообщения фиксации с вашим bugtracker, чтобы автоматически выяснить, какие файлы были затронуты в отношении каких проблем, а затем убедитесь, что все проблемы фактически закрыты для файлов, которые вы хотите объединить. Это нетривиальная задача, особенно если вы думаете о слиянии только частей ветвей. Таким образом, что-то вроде слияния функций.
  7. используйте тег для выпуска. Вы можете проверить это как ветвь и добавить патчи, если это необходимо
  8. Список всех коммитов svn для всего репозитория на одной странице (например, обзор trac/redmine/jira)
  9. используйте локальную копию, я боюсь / или ветку снова. Или сделайте R&D использовать git svn локально для исследований.

некоторые из этих проблем могут, по крайней мере частично, быть решены с помощью git svn. Используя его, вы можете, например, экспериментировать локально с использованием функций ветви gits, не сохраняя их в глобальном репозитории. Из конечно, это не интересно, если вы изучаете новую функцию со многими членами команды, если они все не комфортно с использованием git и потянув друг от друга по сети. Используя git svn вы также можете использовать git cherrypick для ручного выбора одиночных коммитов для применения из одной ветви в другую (например, разработка на released-x.x-tag).

это все, что я мог придумать на данный момент, Надеюсь, это поможет.

2

в своей деятельности я использую SVN со следующим подходом.

  1. Trunk-это ветка" master". Вы никогда не должны совершать ничего прямо в багажнике. Багажник всегда должен соответствовать точно последней выпущенной версии в производстве. Таким образом, ствол всегда представляет собой стабильную ветвь. Ствол обновляется только с реинтеграцией ветвей.

  2. вам нужны ветви для вашей работы. Каждая новая ветвь должна быть создана из ствола, поэтому каждая новая ветвь совпадение точно с производственной версией во время создания. Изменения и исправления фиксируются в ветвях.

  3. У вас должно быть не менее 2 основных ветвей:

    • develop: предназначен для будущих разработок, которые еще не запланированы к выпуску.
    • исправление: используется для фиксации всех исправлений и только исправлений. Для частой пользы, его нужно уточнить с версией хобота когда хобот уточнен.

  4. создать ветвь для каждого основного потока работы: проект, подпроект, запрос на изменение. Можно работать с параллельными разработками.

  5. создайте ветви "интеграции", чтобы присоединиться к ветвям, которые вы должны освободить. Вам нужно объединять в ветвь интеграции каждой ветке candidated до релиза. Таким образом, ветвь интеграции может присоединиться к исправлению и проекту, например.

  6. создайте свои артефакты из ветвей интеграции или из ветвей личность.

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

  8. после того, как ветка выпущена, вам нужно обновить магистраль. Чтобы вернуть ветку в багажнике. Вы можете реинтегрировать ветвь интеграции или ветвь напрямую (если вы не прошли из интеграция.)

  9. когда магистраль снова сопоставляется с производственной версией, сообщите об этом во всех своих активных ветвях.

этот метод на самом деле не является копией концепции git-flow, но он следует некоторым из его требований.

при таком подходе вы можете иметь следующие преимущества:

  • багажник стабилен. Вы всегда знаете, что представляет собой ствол в этот момент.

  • каждый ветка содержит только собственные изменения.

  • с помощью ветвей интеграции вы можете управлять параллельными ветвями в одном выпуске

  • с тегами у вас всегда есть копия выпущенной версии

недостатки:

  • много филиалов для управления.

  • вам нужно объединять и переключаться очень часто, особенно для того, чтобы сообщать об изменениях в интеграции ветви

  • много конфликтов, чтобы решить каждый раз

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

0