I was wondering what the best approach to resolving merge conflicts in a certain scenario was. In this scenario there are two developers(A and B) collaborating on a project together, developerA is the project maintainer therefore should be in charge of any change to the main branch of the project. DeveloperB develops a feature in a new branch(lets call it feature-branch), creates a pull request for it with destination branch pointing at the main branch. Both developers reviews the pull request and sees everything checks out except that some conflicts exists within some files.

I get that conflict-resolutions occurs locally so either or both developers have to resolve the conflicts in their local repo(s).

But my question is in what order should the developers merge the branches together?
Is it merge the feature-branch into the main branch? or merge the main branch into the feature-branch?

>Solution :

If you merge into the feature branch, you can (re-)review the merge result before it finally being merged into the main branch. Git is clever enough to figure out what needs to be merged once you "merge the merge".

If you merge into the main branch, you cannot review the merge result. But maybe it’s not necessary if the maintainer of the project is doing the merge.

A third option is to create a new "integration" branch off of main, merge both branches, then merge that integration branch into main. Not much of a benefit over merging into the feature branch directly though (except sometimes your workflow forces you to do this; it also allows you to continue working on your original feature branch).

In the end, it doesn’t really matter, because you can end up with the same good result or the same bad result.