3

We use feature/develop/master branches for our development. When a feature is done (Let's call it feature/123) we send a pull request to merge to the develop. Sometimes this merge has conflicts so we use Github to resolve the conflict.

My question is why would github merge the entire develop branch into feature/123 after resolving the conflict? I just wanted to merge the feature branch INTO develop not the other way around.

MMM
  • 31
  • 3
  • Can you reconstruct this? Maybe with detailed steps or a public repo? What you describe is generally not expected behaviour (unless specified). – LinFelix Jan 22 '20 at 20:28

2 Answers2

2

This is a pretty old question, but I got myself on the same situation and trying to figure a reason for this. I could find another answer on stackoverflow about the same topic, which goes deeper on the implication of this. You (and anybody that might have the same question in mind) can find it here: Github resolving conflicts always merges base branch to my current branch

Henrique Aron
  • 1,316
  • 1
  • 5
  • 6
0

I'm only speculating but I think the idea is that GitHub wants you to resolve the conflicts in feature/123 instead of resolving them in develop. Which is why it would merge develop into feature/123.

For later reference here's where GitHub documents this behavior:

Warning: When you resolve a merge conflict on GitHub Enterprise Server, the entire base branch of your pull request is merged into the head branch. Make sure you really want to commit to this branch. If the head branch is the default branch of your repository, you'll be given the option of creating a new branch to serve as the head branch for your pull request. If the head branch is protected you won't be able to merge your conflict resolution into it, so you'll be prompted to create a new head branch. For more information, see "About protected branches."

Darren Embry
  • 155
  • 1
  • 2