Консультирование по нескольким линиям выпуска и git -flow, для git не-гуру

Наша линейка программных продуктов требует разработки и поддержки нескольких версий программного обеспечения одновременно. Мы относимся к Git новичкам и недавно приняли Git Flow, чтобы воспользоваться модель ветвления Driessen. У нас очень небольшая команда разработчиков программного обеспечения с несколькими специализированными разработчиками (все мы носим много шляп) и нет "интеграционного гуру".

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

Ключевой вопрос заключается в том, что другие считают хорошим подходом для максимально возможного внедрения разветвляющейся модели Driessen, поддерживая несколько строк выпуска?

ОБНОВЛЕНИЕ:

Переопределение ответов ниже (особенно @Rasmus) с более целенаправленным поиском и внутренними обсуждениями по нескольким вариантам приводит к следующему решению, которое мы реализуем, и которое я предлагаю в качестве одного из подходов, которые могут иметь отношение к аналогичным группам при аналогичных условия.

Мы не будем продолжать использовать Git Flow. Вместо этого мы применим модель Driessen к каждой отдельной строке выпуска в репо, предваряя каждое имя ветки своей предполагаемой версией, например:

r1.5/develop

Все версии проекта содержатся в репозитории Git. Запуск новой версии проекта состоит в создании небольшого набора новых долгоживущих ветвей, предваряемых строкой выпуска (например, r1.6/develop и, в нашем случае, r1.6/release; no master с ее импликацией единственного действующего хорошего строительного состояние).

Мы устанавливаем один центральный публичный репозиторий для каждого проекта на сервере, который станет основным средством для обмена кодами через локальные ссылки репо remote. Толчок к этому репозиторию означает код, который готов к употреблению другими. Объединение RX.Y/develop в, а затем нажатие ветки RX.Y/release означает код, предназначенный для выпуска. feature, hotfix, et. и др. ветки обрабатываются аналогичным образом. История слияния/фиксации ветки для данной строки выпуска является чистой и понятной. Мы не хотим, чтобы типичная стратегия репо с Git заключалась в том, чтобы избежать сложности слияния таких репозиториев, которые со временем могут расходиться в структуре.

В некоторых графических файлах Git (например, SourceTree) эта структура ветвей распознается и отображается как иерархическая, что помогает понять историю проекта верхнего уровня из структуры ветвей.

Извините, что не голосовал ни за какие ответы; моя репутация на SO еще не минимальна для этого.

Ответ 1

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

Мы разделили его так, чтобы у нас был исходный ref, например refs/heads/platformX.Y/, затем мы строим на этом

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

Это работает для нас, и мы можем следовать модели nvie.

поверх всего, что мы объединяем все эти ветки platformX.Y в нашу основную ветку разработки, поэтому исправления ошибок, исправленные на этих ветвях, также выпускаются в последнее программное обеспечение.

Ответ 2

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

Например, наша следующая нормальная версия - 23,0, а наша специальная версия с песочницей - 22.4.2. Для этих случаев мы:

В начале, перед созданием новых функций, создайте ветвь release 22.4.2 для специальной освобождения от разработки. Это нормально, если некоторые функции были начаты ранее, если они не приходят после какой-либо работы по разработке, которую мы хотим исключить.
Создайте тег для удобства (start-22.4.2)
Запустите каждую новую функцию 22.4.2 с помощью start-22.4.2 (набор изменений при разработке), поскольку он является родительским/базовым. Это предотвращает любую совместную работу, чтобы развиваться в то же время от утечки на ветвь выпуска. И командная строка, и Sourcetree поддерживают выбор родителя, кроме подсказки для git flow feature start.
Слейте вручную с кончика ветки 22.4.2 на функцию, если это необходимо, и так часто, как требуется, чтобы выполнить любые завершенные функции из ветки. Это позволяет нам рассматривать любые взаимодействия, вызывающие озабоченность, среди новых функций 22.4.2 на ветке.
git flow feature finish функция, которая объединяет ее, чтобы развиваться как обычно. (Для нас эти функции предназначены для включения в будущие выпуски. Мы защищаем только 22.4.2 от менее проверенных работ.)
После finish мы вручную объединим последний набор изменений перед закрытием функции на ветке 22.4.2.

Ответ 3

Одно из решений - изменить конфигурационную переменную gitflow.branch.develop. Вы создаете ветвь в своей выпущенной версии и используете эту ветку в качестве новой ветки разработки. Оттуда вы используете обычные команды git -flow. Если вы хотите автоматически объединить эту работу в исходную ветвь разработки, измените переменную gitflow.branch.develop перед командой git -flow finish.