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

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

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

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

ОБНОВЛЕНИЕ:

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

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

r1.5/develop

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

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

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

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

Ответы на вопрос(3)

Ваш ответ на вопрос