1

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?

redd
  • 33
  • 6
  • There might be an invalid premise in your question. Pull Request functionality is tool specific, but the tools I've used won't let you review a PR *before* conflicts are resolved. – TTT Mar 12 '23 at 18:28
  • As for how to resolve them, you could merge the target branch into feature branch, or rebase the feature branch onto the target branch. There are Pros and Cons to each but from what I've read in your question I'd personally lean towards rebase. – TTT Mar 12 '23 at 18:32
  • @TTT Ok thanks man, well my particular cloud service allows creating a pull request but prevents a merge to the target branch until conflicts are resolved. My confusion was if it was a good practice to merge target branch into feature branch( I always thought it was always merge featureB onto targetB ) – redd Mar 12 '23 at 18:36

1 Answers1

1

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 the other branch, 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.

knittl
  • 246,190
  • 53
  • 318
  • 364
  • Thanks I totally agree with this. – redd Mar 12 '23 at 18:37
  • @TTT yes, there are 2 branches, but you could create a _new_ branch, do the merge, merge the result. This allows you to continue working on the original branch – knittl Mar 12 '23 at 18:40
  • That third option is kind of handy in a scenario where you want **only** the commits associated with a particular feature in the feature-branch. – redd Mar 12 '23 at 18:43
  • 1
    @TTT ah thanks, that is confusing indeed. I have changed the wording. Thanks for double-checking! – knittl Mar 12 '23 at 20:01