Git branching model для улучшения аппетита и нормализации цвета лица

Некоторое время назад, мы столкнулись с проблемой не совсем правильной организации git-окружения. Проблемы заключались в преждевременном мерже фич в основную ветку и отсутствии четкого понимания что в какой ветке должно находиться. С этим нужно было что-то делать.

Прочитав несколько публикаций в блогах у меня сложилось впечатление, что автора соревнуются в создании самой сложной и бессмысленной системы ведения репозиториев, вот один из типичных примеров: http://nvie.com/posts/a-successful-git-branching-model/
Основная проблема авторов публикаций — попытки усложнить изначально простую и продуманную систему, к примеру:

• вести production-код в ветке master (Зачем? Это дефолтная ветка и она изначально предназначена для development)
• использовать rebase веток (Нафига превращать git обратно в svn?)
• вести несколько параллельных development-ветвей вместо принципа одна ветка — одна фича.

… и т.д.

Немного помучившись, я взял за основу схему которая отлично работала на одном из проектов, формализовал некоторые моменты и стандартизировал процесс принятия в production. Получилось следующее:

Общий принципы данной модели:

• Одна фича — одна ветка
• Master в конце итерации становится staging, оттестированный staging становится production и так по кругу. Master не может стать production, staging без хорошего тестирования не может стать production.
• Активно используем теги, это позволит нам не превращать репозиторий в кашу и быстро откатываться в аварийных ситуациях
• Фичи из веток показываем гемом proxylocal или подобным сервисом, это позволяет не заводить на сервере кучу environments и не ебаться каждый раз с деплоем, только потому что клиент захотел посмотреть на новые кнопочки.

С большой радостью выслушаю конструктивную критику и предложения по улучшению.