I found the way to solve Pull Request conflict is not very intuitive. Could someone give some further explanation or reasoning?
Scenario:
Two developers opened two PR at the same time. One is PR1 from branch feature-1 and the other is PR2 from branch feature-2, and they both edited a same file which will lead to conflict.
PR1 is first merged sucessfully. But PR2 now has conflict to resolve. The "official" way to resolve this is:
- in local, pull the latest main, and merege main to branch feature-2 (and resolve the conflict here);
- Push branch feature-2 to remote. And now PR2 can be proceeded.
And the network looks like as followed
My question is why cannot we just resolve the conflict by merging feature-2 into main (i.e., address the conflict directly in this step)?
In contrast, in the "official" way, we have to merge main to feature-2 and then merge back to main. It is not intuitive and tends to create confusing commit history. The only reason I can think of is the designer of PR workflow considers it is the feature developer's responsibility to resolve conflict rather than the main branch owner.
All tutorials I checked show the "official" workflow, and I believe it is the common practice. But I found it is not very intuitive. I am looking forward to more reasonings and insightful comments.
CodePudding user response：
When you work together with many other users, e.g. your colleagues in a company, there is often one master copy of the repository, located on a server like gitlab. There you are often not allowed to push something to the main branch directly. You can only ask the server to merge a branch to main, but this works only if there are no merge conflicts. So you have to solve the merge conflicts on your branch so that this branch can then be merged without conflicts.
Sometimes there can also be a restriction on the server which allows only fast forward merges. This means, you can only merge if your branch has no difference to the intended state of the main branch after the merge.
If you are working alone on a git repository and have full access to everything, it is perfectly ok to just merge to main and solve the conflicts while merging.
CodePudding user response：
Continuous-deployment workflows generally have checks that run unit or functional tests on PR branches' code before enabling the big green "Merge pull request" button, so they prohibit pushing the main branch to prevent untested code being committed or merged.
CodePudding user response：
Actually, sometimes you can do it on the target branch. Pull Request functionality is not inherently part of Git, and so is tool dependent, but some tools offer limited merge conflict resolution directly in the UI, for example:
Side Note: To resolve locally you don't have to merge the target into the feature branch. In most workflows you can rebase the feature branch onto the target first to avoid the new merge commit on the feature branch. (Obviously you can't do this on shared branches, but typically is fine for "feature" branches.)