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

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

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

Как мы разрабатываем параллельный код для этой версии и последующих выпусков?
Какой код считается стабильным?
Что (в разработке) код входит в следующую версию?
Что (в разработке) код входит в следующую версию?
Какая версия кода является нашей тестовой, приемной или производственной средой?
Как мы интегрируем параллельные действия разработки с известным стабильным выпуском, чтобы уменьшить ввод ошибок и неполную работу?
Как предоставить горячие исправления выпущенному коду?
Как мы знаем, из нашего источника контроля, какая деятельность в настоящее время продолжается?
Как мы экспериментируем или R & D без нарушения текущей базы кода при использовании?

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

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

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

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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