Рабочий процесс веб-разработки Git: жонглирование публикацией срочных исправлений и нескольких этапов

Мне нужна помощь в планировании того, как будет идти рабочий процесс для конкретной среды разработки сайта, недавно преобразованной в Git (из SVN).

У меня есть 4 разработчика, действующие и промежуточные сайты на клиентском сервере, а также сервер разработки, на котором размещается «хаб» (голое репо) плюс 2 репозитория разработчиков. У нас есть несколько этапов изменений, над которыми нужно работать, с неизвестным порядком завершения и над которыми работают несколько разработчиков. Кроме того, действующий сайт требует множества быстрых исправлений, делаемых на лету.

Мои основные вопросы:

• Как следует вносить срочные исправления
• Как должна происходить публикация вехи изменений

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

У каждого репозитория разработчиков, репозитория концентратора и репозитория стадии есть эти ветви: мобильная, редизайн, мастер. В реальном репо есть одна ветка: master

. БЫСТРЫЕ ИСПРАВЛЕНИЯ: разработчик вносит изменения в свою главную ветку, нажимает на хаб. Затем в режиме реального времени извлекает изменение из концентратора (или сначала на этапе, если им нужно предварительно там протестировать).

ЗАКЛЮЧИТЕЛЬНЫЙ ЭТАП И ПУБЛИКАЦИЯ «РЕДАКТИРОВАНИЯ» ЭТАП: разработчик перемещает ветку редизайна в концентратор и вносит изменения на этапе. Клиент тестирует и утверждает. В хабе разработчик объединяет редизайн с мастером (и, думаю, здесь создает тег), а затем тянет мастер вживую. Или разработчику было бы лучше объединить ветки в своей копии, а затем просто отправить своего мастера в хаб. Кроме того, если тег создан, лучше ли просто вытащить тег (если возможно) в реальном времени, а не вытащить основную ветку? И должны ли теги находиться только в репозитории концентратора?