Наш предыдущий рабочий процесс был похож на gitflow, все ответвляется от мастера, мастер всегда отражает производство. При подготовке релиза ветки фич сливаются в мастер, возможные конфликты между разными фичами исправляются, создаем тег для релиза, нажимаем на мастер и все.
Итак, теперь мы хотели бы интегрировать пул-реквесты в этот рабочий процесс, но пусть разработчик ветки останется ответственным за исправление конфликтов. Идея заключалась в том, чтобы по-прежнему ветвиться от master, а затем делать запрос на включение в новую ветку, называемую releaseX, где находится весь новый код, который входит в следующий релиз.
Проблема в том, что когда в релизе X возникают конфликты между новой функцией и другими функциями, как разработчик их исправляет? Выполнение слияния в самом github неприемлемо, слияние releaseX с веткой функций также неприемлемо (это приведет к включению несвязанных функций и затруднит выпуск функции в конце концов).
В итоге мы создали ветку только для слияния, что-то вроде разрешения/релизаX_my_beautiful_feature.
(На данный момент следование более похожей на githubflow модели (вместо gitflow) с непрерывным развертыванием и отсутствием реальной концепции релизов — не лучшее решение для нас.)
Ребята, какой рабочий процесс вы используете при использовании как запросов на включение, так и релизов?