Избегайте слияния проблем в ветках функций разработчиков, чтобы не испортить историю основной ветки.

Недавно мы мигрировали с SVN -> Git (используя Stash). После миграции мы начали замечать проблемы во время слияния, когда некоторые разработчики портят слияние в своей функциональной ветке.

**Our workflow model:-**

master    1---2----3------------4----5
            | |        |   |    |    | 
            | |        M   |    |    |  
feature1    | a--------b---     |    | 
            |                   M    |
feature2    c-----------------d-------

На приведенном выше рисунке допустим, что у developer1 есть функциональная ветвь feature1 , он внес свои изменения и снова объединился для разработки.

У Developer2 есть ветка, которая была создана до ветки developer1, но будет существовать дольше. Как только изменения внесены, он загружает изменения из master в свою ветку, разрешает любые конфликты, а затем снова объединяется.

Проблема в том, что когда developer2 объединяет изменения в свою локальную ветку, он разрешает конфликты слияния, отдавая предпочтение своим собственным файлам. Однако на самом деле это переопределяет некоторые файлы, которые он не изменил. Когда он создает запрос на вытягивание и сливается обратно с мастером, он эффективно откатывает изменения developer1 к предыдущей версии. Мы можем запустить это, потому что файл фактически откатывается к предыдущему идентификатору фиксации (SHA).

Вопрос в том,

1. есть ли способ избежать этого систематически, т.е. попросить git отклонить любые изменения в мастере, где идентификатор изменения SHA на самом деле является откатом.
2. Есть ли способ при слиянии, когда разработчики получают конфликты только на те файлы, которые они изменили

Мой гуглинг привел меня к статьям, в которых предлагалось выполнить git pull с параметром --rebase или изменить разрешение на основную ветку, чтобы они разрешали только быстрые слияния. Поможет ли любой из вариантов.