If a pull request from branch A to branch B has conflict found, after resolving it, the merge always happens in bidirectional way. Why is it so?

Question

When we merge a pull request from branch A to branch B, we expect only the changes in branch A to go into branch B. If there's no conflict found in the pull request, the merge behaves just like we expect. However, if there's any conflict, after we resolve it, and then perform merge action, all changes from branch B also go into Branch A. Why does GitHub merge in this way?

The following steps outline the process to reproduce this phenomenon for 2 scenarios.

1. a pull request with conflict found:

   1. The main branch has a file called a.txt, which contains only one line of text.

   2. A feature1 branch is created from the main branch, and the line of text in a.txt is modified in the feature1 branch.

   3. Then, in the main branch, the same line of text in a.txt is modified, and a new file called b.txt is added as well.

   4. At this point, a pull request is submitted from the feature1 branch to the main branch.

   5. The pull request shows a conflict, and after resolving the conflict and merging, it is found that b.txt from the main branch is also merged into the feature1 branch.

2. a pull request without conflict found:

   1. The line of text in a.txt is modified again in the feature1 branch.

   2. The main branch does not modify a.txt, but adds another new file called c.txt.

   3. A pull request is submitted from feature1 branch to main branch.

   4. The pull request shows no conflict, and after merging, it is found that c.txt from the main branch is not merged into the feature1 branch.

Conclusion: When resolving conflicts in a pull request and merging, changes from both branches will be merged bidirectionally, resulting in the main branch and feature1 branch having identical content. However, when there is no conflict in the pull request, only changes from the feature1 branch will be merged unidirectionally into the main branch, and any changes in the main branch will not be merged into the feature1 branch.

Question: I don't understand the bidirectional merge behavior with the conflicts found in a pull request. This is not what I expect. I want to just bring the changes from the feature1 branch to the main branch in my pull request, without bringing the changes from the main branch back to the feature1 branch after the merge. Can anyone tell me the reason?

I've provided all details in the question content.

Answer 1

This is not what I expect. I want to just bring the changes from the feature1 branch to the main branch in my pull request, without bringing the changes from the main branch back to the feature1 branch after the merge.

For that, you need to rebase your feature branch on top of the target branch (main).

Assuming you did branch from main (older commit):

git switch feature_branch
git fetch
git rebase origin/main
# resolve any conflict locally
git push --force

Your PR will be updated, and the changes eligible for merging in that PR will be only the feature_branch.