避免合并开发人员的功能分支上的问题，以免混淆主分支的历史记录

Question

We recently migrated from SVN -> Git (using Stash) . After the migration , we have started seeing issues during merge where some developers are messing up the merge on their feature branch.

**Our workflow model:-**

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

In the above figure lets say developer1 has a feature branch feature1 , has done his changes and merged back to develop.

Developer2 has a branch that was created before developer1's branch but is going to be around for a longer time. Once the changes are done, he pulls in changes from master into his branch , resolves any conflicts and then merges back in.

The problem is that when developer2 merges changes into his local branch he is resolving merge conflicts by preferring his own files. However, this is actually overriding some of the files that he has not changed . When he creates a pull request and merges back to master, he effectively rolls back the changes of developer1 to the previous version. We can fire this out because the file actually rolls back to the previous commit (SHA) id

The question is,

1. is there a way we can avoid this systematically ie ask git to reject any changes into master where the change SHA id is actually a rollback.
2. Is there a way during the merge when developers get conflicts only on the files that they have changed

My googling brought me to articles which suggested doing a git pull with the --rebase option or changing the permission on master branch so that they will only allow fast-forward merges. Will either of the options helps.

Answer 1

Welcome to git. this is where you realise it's not magic, merging issues haven't disappeared, and you still need to merge like you always did.

The answer is to ensure developers merge correctly, and no tool in the world will force you to do that. It's a people problem ultimately.

I would recommend code reviews that are mandatory for all push requests back to origin, or merging to master. One of the reviews will be to inspect the history to see if any such overrides has occurred with appropriate censures.