Модель ветвления Git в Open Source проекте

Question

Мы работаем над проектом с открытым исходным кодом, который использует несколько веток версий:

Пример: master, 1.1 (LTS), 1.2, 1.3 (LTS), 2.0....

Мы используем в производстве предыдущую LTS, чтобы иметь максимально стабильную ветку.

Наша проблема:

Мы находимся на 1.1 и имеют сотни коммитов. (незавершенный PR или внутренние изменения). Нам нужно перейти к 1.3

Существует новая версия ветки каждые 3 месяца. Так что этот процесс должен быть максимально безболезненным и эффективным

Возможные решения:

• сращивание 1.1 в 1.3, Поскольку два дерева имеют длинное расходящееся дерево, я не уверен, что это лучший подход
• Черри выбирает наши коммиты из 1.1 в 1.3, Не уверен, что это лучшая идея, так как нам придется выбирать все эти коммиты от версии к версии.

Есть ли у вас какие-либо предложения или рекомендации?

Спасибо

Answer 1

Спустя чуть больше года и много релизов, мы сделали следующее:

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

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

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

Answer 2

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

Смотрите git flow, где они вызывают промежуточную ветвь разработки: https://www.atlassian.com/git/tutorials/comparing-workflows