0

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:

  1. in local, pull the latest main, and merege main to branch feature-2 (and resolve the conflict here);
  2. Push branch feature-2 to remote. And now PR2 can be proceeded.

And the network looks like as followed

enter image description here

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.

CX_Lin
  • 23
  • 4
  • The thing is, git is pretty much diff-based. Every commit is a diff, a change between "how it was" and "how it is now". Having some changes in the *main* from the *feature-1* indeed prevents you from merging *feature-2*, because there *is* a diff in "how main is now" and "how feature-2 expects main to be". In order to resolve that, you need to update your *feature-2* branch first with the latest changes in *main*, so the diffs are consistent. It is slightly un-intuitive at the first glance indeed, but you'll get used to it once you get whats going on under the hood. – Vitalii Vasylenko Jan 25 '23 at 20:29
  • 1
    Even though I agree with the core of @VitaliiVasylenko's comment, I want to make it clear that git does _not_ keep diffs between commits. It has a full snapshot of the contents of all files for all commits. – eftshift0 Jan 25 '23 at 20:35
  • To git, it actually makes no difference merging a into b or b into a.... results will be the same (same conflicts will show up), only the order of the parents in the merge commit would differ. Then, the point of telling you about the conflict and letting you take care of it is that _it is your code_... why would a 3rd party be involved in getting it merged in `main`? Who would be better suited with handling conflicts with your code? Just in case, it would be fine for another person to do the merge, as long as they have visibility of both branches, just it is better if you do it, in principle. – eftshift0 Jan 25 '23 at 20:40
  • And, by the way, this is because you are allowed to do the merge in the repo config in the hosting.... on certain workflows (gatekeeper, for instance) it has to be someone else who does the merge. – eftshift0 Jan 25 '23 at 20:42
  • Just to make it clear, by diff,i mean that every commit has only changes made in file, not a whole file itself. E.g In Commit1 you've added new file,a config with 100 lines -you see that in commit. In Commit2 you've added 2 new lines to that config - so Commit2 contains only the diff,those 2 lines,not the whole file of 102 lines. That is an important part of my explanation, because when merging 2 lines from *feature-2* branch,you need to ensure those lines were not changed in previous commit,made by marging *feature-1* branch. So,before the merge you have to ensure you have actual code – Vitalii Vasylenko Jan 28 '23 at 16:40

3 Answers3

0

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.

Donat
  • 4,157
  • 3
  • 11
  • 26
0

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.

Nic Wolff
  • 73
  • 1
  • 3
0

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:

  1. GitHub
  2. Azure DevOps
  3. GitLab

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.)

TTT
  • 22,611
  • 8
  • 63
  • 69