Упрощение рабочего процесса git

Question

При попытке упростить:

при наличии требований:

1. Запуск параллельных мастеров
2. Запуск ветвей объектов, которые могут / не могут быть выпущены
3. Обработка исправлений
4. Исправление уязвимостей

Глядя на Успешная модель ветвления Git

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

Можем ли мы покончить с разработкой ветки?

Ветвь релиза может быть разветвлена ​​от мастера в начале нового спринта, и разработчики могут создавать свои ветки возможностей из этого. Если слияние исправления с главным (текущим выпуском) происходит в середине спринта, исправление также можно объединить с текущим выпуском ветви одновременно с feature-branch-hotfix-

Код из ветвей Feature / Develop следует развернуть в среде DEV

Функциональные ветви сами по себе не должны развертываться вообще.

Предпочитаю мою стратегию, в которой запрос на слияние из release- * master запускает сборку конвейера jenkins через webhook, которая автоматически объединяет release- * master, сборку master и помечает коммит слияния.

Answer 1

Если вы хотите более простой (и более гибкий) рабочий процесс, рассмотрите gitworkflow .

Вы не делаетеобъединить dev в master: вы объедините только feature ветви.

Объедините feature ветви в:

• dev для интеграционного тестирования
• master для подготовки следующего релиза
• другой ветки release, если вы ведете / готовите несколько выпусков параллельно

I подробнее об этой модели здесь и проиллюстрируйте это здесь

Один важный момент: ветвь dev (для объединения ветвей feature) является переходной : она создается / уничтожается для каждогоновый выпуск (в отличие от одной фиксированной вечной ветви dev, время от времени объединяемой с master).

Вы воссоздаете столько веток интеграции, сколько необходимо для тестирования функций вместе.
Затем, когда все готово, вы объединяете только правильные ветви feature в master (или любую другую ветку release),удалите ветку dev и заново создайте ее для следующего выпуска.