Сегодня популярен подход в разработке приложения, имя которому Git Workflow. Бывает доходит до такого, что на вопрос, используете ли вы данный подход, удивленно отвечают: «а кто его не использует?». На первый взгляд — это действительно удобная модель, простая и понятная, но тот, кто ведет разработку с большим количеством участников знает, насколько сложны и утомительны порой бывают мерджи. Какие тяжелые конфликты могут возникнуть и какая рутинная работа их решать. Уже в команде из двух разработчиков можно услышать вздохи о предстоящем слиянии, что говорить про 10, 20 разработчиков? Плюс зачастую есть три основные ветки — (условно) dev, staging, prod — которые тоже кто-то должен поддерживать в актуальном состоянии, тестировать и решать конфликты слияний. Причем не только в одну сторону, а и в обратную, ведь если на продакшне оказывается баг и срочно нужно что-то предпринимать, то нередко хотфикс уходит в продакшн, а потом мерджится в другие ветки. Конечно, если тим-лид или другой счастливец, ответственный за выкладку, — полу-робот, то проблема раздута. Но если есть желание попробовать другой вариант разработки, то под катом есть предложение супер-зелья.
