git ветвление для поддержания нескольких выпусков

Question

Я рассматриваю способ управления филиалами в git repo в нашем проекте. Я читал famous article, и мне очень понравилась идея, и, похоже, эта модель должна быть полезной для нас.

Однако в статье есть скрытое предположение, которое происходит из-за существования ветки master: последняя версия, тем больше ее версия. Например, 2.0.1 выпускается всегда после 1.5.10. Поэтому, когда вы проходите каждое коммитирование в master, версия всегда будет увеличиваться.

Это не относится к нашему корпусу проекта. Мы должны поддерживать несколько версий для разных клиентов. Для одного клиента мы должны поддерживать (и доставлять исправления) для версии 1.5, для другого клиента - 2.0. Очевидно, что версия 1.5.10 в нашем случае может быть последней (с точки зрения времени), чем версия 2.0.1. Фиксирование 1.5.10 в master после 2.0.1 было совершено, не имеет смысла.

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

Answer 1

Мастер должен отражать только текущую версию, вот как я ее реализовал. Любая другая версия находится на ветке.

например

V1 (master) -> -> -> \/ -> V2 (master) 
    v2 -> -> -> -> /\ -> V1 (no longer master) 

совершающее на ветви V1, больше не является частью основной истории и истории V2, была объединена с мастером. Поэтому ни одна история не должна конфликтовать в ваших журналах.

Answer 2

Известная практика имеет разные ветви для соответствующих основных выпусков.

master по-прежнему выступает в качестве основной отрасли интеграции.

Чем больше вы должны поддерживать свои ветви освобождения отдельно, но и решать, какие коммиты вы хотите доставить в каждую ветвь освобождения.

Всегда полезно ознакомиться с известными проектами, которые вы знаете, чтобы принять свою модель выпуска и изучить их политики хранилища. Вот хороший пример сохранения нескольких основных выпусков с использованием git scm https://github.com/django/django/branches