Павло Пономаренко

У вас есть целевая ветка development, и несколько веток фичей: feature_1, feature_2.

1) после (почти?) каждого принятого пул-реквеста все программисты мержат development в ветку своей фичи
2) ветка фичи по возможности делается минимальной и заливается на development как можно быстрее

Так конфликтов будет максимум на 5 минут и не будет необходимости параллелить мердж. А при любой непонятке вы зовете человека, который сделал успешный пул-реквест и вдвоем разбираетесь в этом.
Судя по тому, что вы в девелопмент стараетесь запушить, а не выходит - вы не делаете мердж с девелопментом каждый день и собираете все конфликты, откладывая их на последний день.

Конфликт будет, но он должен быть во время pull. Допустим, мы в ветке master:

git commit -m "Мои изменения"
git pull
/// резолвим конфликты
git commit -m "Конфликты зарезолвены"
git push

Резовлит тот, кто делает pull, но он может позвать для консультации всех, кого необходимо. В случае git-flow разработчик работает в ветке feature-branch

git commit -m "Мои изменения"
git pull
/// резолвим конфликты с другими разработчиками, которые разрабатывают feature
git commit -m "Конфликты зарезолвены"
git merge develop
/// резолвим конфликты с мастером
git commit -m "Конфликты с основной веткой зарезолвены"
git push

После этого можно делать pull-request в develop-ветку. Если ветка меняется и снова появляются конфликты - опять делаем merge в feature-branch и push, Pull Request к примеру на ГитХаб обновится автоматически