Git Web Development Workflow: манипулирование публикацией срочных исправлений и нескольких этапов

Question

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

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

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

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

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

Каждый репозиторий для разработчиков, репозитарий-концентратор и репозиторий на стадии имеют все ветви: мобильные, редизайн, мастер. Живое репо имеет одну ветку: master

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

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

Answer 1

Рабочий процесс кажется звуковым, за исключением части "слияния".

Я бы всегда предшествовал любому слиянию с перебазированием первым: разработчик перебазировал свою работу поверх главной ветки, чтобы локально разрешить любой конфликт (как первый сценарий, который я описал в " rebase vs. merge * 1004" * ").
Это сделает любое последующее слияние (после первоначальной перебазировки) ускоренным.

( Jefromi упоминает в комментарии, что перебазирование не всегда возможно.
Правда, всякий раз, когда какая-то работа уже была перенесена / извлечена в другом месте, перебрасывание этой же работы опасно.)

Что касается извлечения тега или мастера в прямом эфире, я бы предпочел использовать только теги, а не HEAD ветви. Это означает, что я бы выставлял «голое» репо в прямом эфире, в котором был бы установлен хук post-receive для обновления не-голого репо (реального живого сайта) с тегом, только если указанный тег находится в HEAD master ветка (которую git describe можно легко проверить)

Answer 2

На мой взгляд, ваш рабочий процесс на 75% в порядке.Вот как я бы это сделал:

Основная концепция заключается в том, что каждая ветвь представляет состояние веб-сайта.Основная ветвь - это текущая работа в процессе, это то, что вы видите на своем промежуточном сайте.Вы создаете «живую» ветку, которая представляет реальный живой сайт.Затем у вас будет столько веток, сколько вам нужно для других задач.

Ваши разработчики помещают свои изменения в репозиторий-концентратор, каждый со своими ветками.Когда вы будете готовы с функцией, вы объединяете / перебазируете свои изменения в основную ветку и перемещаете ее в концентратор.Затем вы синхронизируете эти изменения с промежуточным сайтом.Вы делаете это, пока не будете удовлетворены изменениями.(На компьютере разработчика) вы затем перебазируете живую ветку из главной ветки.Переместите его в концентратор, а затем синхронизируйте (push / pull) с действующим сервером, который обновляет веб-сайт.

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

Наконец, стоит отметить, что, за исключением локальных веток разработчиков, все ветки дублируются во всех репозиториях.Это позволяет каждому увидеть различные этапы работы.