Правильная организация git репозиториев при разработке сайта

Есть выделенные сервер с работающим сайтом.
Необходимо реализовать следующее:
1) живой работающий сайт
2) тестовая копия этого сайта, которая так же доступна в браузере
3) локалные копии тестового сайта у разработчиков, которые вносят изменения в код и отправляют изменения в тестовую копию на сайт
4) после тестирования всех внесенных изменений в копии сайта - перенести все на основной сайт

интересует вопрос - как правильно организовать git репозитории с кодом сайта при такой схеме работы.

1 ответов


Рекомендую обратить внимание на статью A successful Git branching model

Исходя из неё, у вас должен получиться следующий git-воркфлоу:
develop ветка - в ней ведется вся основная разработка
feature-ветки - почкуете их от develop для разработки каких-либо фич, нового функционала и т.п., бек-мерж в develop
release-ветки - для подготовки кода к деплойменту на тестовый\продакшн инстансы, мерж в девелоп и мастер
master ветка и теги для неё - непосредственно стабильный код, готовый для деплоймента на продакшн
хотфикс-ветки для мастер - быстрые фиксы для выявленных недочетов, мерж в девелоп и мастер

Теперь о деплойменте и инстансах
- лучше добавить еще один, доступный из браузера, develop инстанс где всегда будет последний код из develop ветки (либо кроном дергать git pull, либо реализовать с помощью git хуков)
- как только код подготовлен в release ветке, то продеплоить его на тестовый инстанс при помощи Capistrano/Fabric и т.п. утилит предназначенных для деплоймента
- как только код в release ветке проверен и завалидирован как стабильный, то мержить его в master и назначить tag. продеплоить код, соответствующий этому тегу, на продакшн с помощью утилиты для деплоймента

польза деплоймент утилиты заключается в следующем:
- автоматизация действий
- исключение человеческой ошибки (вероятность забыть что-то сделать)
- возможность деплоить сразу на несколько серверов
- возможность отката кода на предыдущую ревизию (в случае непредвиденной ошибки)
- многое другое