Простой релиз-менеджмент средствами Git

Git – это не только удобная распределенная VCS, но и инструмент подготовки релизов.
В статье будет рассмотрен flow на примере Java-проектов на Maven. Статья может быть полезна для разработчиков малых и средних команд, подразумеваются базовые знания git. Материал частично перекликается с git-flow, но здесь описан более простой вариант.
В классическом случае в репозитории существует одна ветка master, из нее же делаются сборки. Если проект собирается при этом на build-сервере, это может привести к беспорядку – несколько разных билдов под одной версией, не ясен набор коммитов, которые попадают в релиз (например, если сборка делается автоматически по триггеру на VCS).

Как решить эту проблему

Первое что можно сделать – ввести вспомогательную ветку release, в которую делается регулярный merge из master (скриншот сделан в TortoiseGit, timeline снизу-вверх). Для maven-проектов в момент merge в pom-файлах версия SNAPSHOT заменяется на релизную. Если все сделано правильно, это единственный конфликт. Желательно ставить тег с номером версии. После этого в ветке master делается major-up SNAPSHOT-версии, таким образом master всегда SNAPSHOT, release – всегда нет. Соответственно, build-сервер настроен на ветку release для production-сборок.
Недостатком варианта с двумя ветками master и release является невозможность сделать хотфикс, не выпуская новую функциональность из master, что может быть критично.

Вводим ветку hotfix

Для этого можно ввести ветку hotfix, которая будет расти из коммита, предшествующего merge’у в release. Первым коммитом в этой ветке будет minor-up SNAPSHOT-версии (на иллюстрации — 1). Далее сделанные исправления мержатся на ветки release и master. При merge в release разрешается единственный конфликт в пользу фиксации не-SNAPSHOT-minor-версии (2), при merge в master версия остается из master (3). После merge в release в ветке hotfix делается minor-up SNAPSHOT-версии (4). Перед очередным major-релизом hotfix мержится в master – таким образом мы не потеряем все исправления. После окончания подготовки веток они отправляются в origin-репозиторий.

Что имеем в итоге

Основные плюсы решения:

• наведение порядка с релизами; одной релизной версии соответствует ровно один коммит
• за счет регулирования прав на репозиторий четко разделяются роли в команде: разработчик, ревьювер, тестировщик / релиз-менеджер
• в случае нормального хода вещей не приходится делать push —force, рискуя затереть чужие правки, вероятность потерять ценные изменения минимальна
• Нет необходимости регулярно создавать новые конфигурации по шаблону на билд-сервере (в отличие от варианта создания новой ветки на каждый major-релиз)
• Схема относительно проста, при этом вполне удобна. Мы используем варианты с двумя и тремя ветками почти во всех своих проектах.

К минусам можно отнести невозможность выпуска hotfix в предыдущем major-релизе. Также невозможно набрать релиз только из нужных коммитов. Это решается усложнением flow и выходит за рамки данной статьи.

Для многих здесь нет ничего нового, но судя по тому же github, аболютное большинство open-source проектов использует самую простую схему с одной веткой.

А какой flow используете вы?

Полезные ссылки: ProGit, Git How To