Github resolving conflicts always merges base branch to my current branch
I am working in my local branch in PHP Storm. After the task is done, I commit my branch and push to git.
On Github page I create a Pull request DEV <- my branch. Dev is the base branch, to which I will merge my branch.
This is ok till now. But in case there are conflicts in some files - according to this article https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/resolving-a-merge-conflict-on-github
In my case the same file was updated in other branch and merged to DEV before. Now in my branch is the same file with other changes.
When I resolve the conflict (can be even one line), I Mark it as resolved and the commit merge.
And now it happens, that the whole DEV base branch is merged to my own branch, and this is not good.
Because I am merging my branch to DEV, not vice versa. How is it possible to avoid this?
I tried to recreate the same branch, but the once the dev was merged here, it is always there. It is nonsense that this happens on each conflict - as the 8. point of above mentioned web says:
Once you've resolved all your merge conflicts, click Commit merge. This merges the entire base branch into your head branch.
tl;dr
the whole DEV base branch is merged to my own branch
This is a feature of Github's conflict resolution process.
From Resolving a merge conflict on Github: "8. Once you've resolved all your merge conflicts, click Commit merge. This merges the entire base branch into your head branch." But they don't explain why.
and this is not good
It is surprising, but it is good. I'll explain below.
How is it possible to avoid this?
Don't avoid it. But it is possible to make the process more smooth.
Bring your branch up to date with dev and resolve any conflicts. Then submit the PR.
To do this on Github: Submit your PR as a draft; resolve the conflict on Github; mark it ready for review. By beginning with a draft you avoid people reviewing your code before the conflict resolution is complete.
To do this on the command line:
# Bring dev up to date
$ git checkout dev
$ git pull
# Update your branch with the latest dev
$ git checkout <your branch>
$ git rebase dev # or git merge dev
Note that yes, you merge dev into your branch before submitting your branch to be merged into dev. This is the normal process of bringing a branch up to date.
You should be bringing your branch up to date habitually to reduce the amount of drift between your branch and dev. This will make the conflict resolutions smaller and easier to manage.
Y U Do This, Github?
The Github PR process, like any review process, is about checking the resulting merge will work. This can involve automated checks, running the branch's tests, and manual review.
Let's consider if it worked like you want. Your PR passes all checks. You click the merge button and there are conflicts. You resolve the conflicts and merge straight into dev.
What if you made a mistake resolving the conflict?
The resolved code is not the code that was reviewed. A merge conflict indicates something changed in dev that you were unaware of and did not account for. You just edited your branch to fix that, and that work has not been checked. If merged immediately into dev there's nothing stopping your PR from breaking dev for everyone.
Instead, a Github PR needs to treat manual conflict resolution like any other edit. As with any other edit, it must be rechecked. The resolved code must live somewhere in the repository. So Github merges dev into your branch along with the conflict resolution, just like if you'd updated your branch before submitting a PR. Now your branch can be rechecked for mistakes. The resolved code passes checks it can safely be merged.
So Github is doing the same thing you should be doing on the command line. Update your branch from dev, resolve any conflicts, check the result, then merge.
Note: this is an educated guess on my part. I don't have any special insights into Github.
In the end, feature branches are ephemeral. Once merged they should be deleted. The exact merging process isn't too important so long as the result is correct.