Merge request also modifies source branch

I noticed some puzzling behavior when using the GitLab Merge Request feature. I created a merge request to merge feature into develop. The feature branch lacks some of the recent commits made to develop. I was under the impresssion that develop would gain the code from feature, while feature would be left unmodified.

What I noticed after merging is that in addition to the resulting merge commit titled “merge feature into develop”, the process also created an additional merge commit titled “merge develop into feature”. Now both feature and develop are identical which is not what I was expecting. The extra commit appears in the completed merge request page in the “discussion” tab.

I want Feature to remain as it was instead of being forcefully synced with develop. What is the source of this additional commit and can it be disabled in GitLab?

We ran into this problem on our local gitlab service and were able to reproduce the problem on It seems to only happen when there are merge conflicts. I haven’t been able to find any way to work around the problem other than to do merges using git on the command line until this is corrected. I’ve submitted an issue with gitlab project a few days ago, but apparently it hasn’t been reviewed yet.

Apparently this is “by design”.

In my case I plan to work around it with one of the following:

  1. Create a new temporary branch off of the source branch, and merge the temporary one into develop. The original source branch won’t be altered.
  2. Resolve conflicts locally with a rebase prior to creating a merge request
  3. Merge locally in such a way that the conflicts are resolved in the target branch, not the source branch (The default git merge works in this manner)

Yes, it does appear to be an intentional design. I think we’re going to end up using work around #3 for the most part. This seems like an incredibly poor design and I’m not sure why it was ever implemented this way to begin with. The “Merge” behavior in the UI does something very different from what “merge” does with the git command. That alone is very misleading. The second issue is that the same merge operation (from the UI perspective) behaves very differently depending on whether or not any given merge request happens to involve conflicts or not. I can’t believe this hasn’t created more problems than it has solved for users.

The ticket comments I linked above are full of people reporting unintentional changes to the source branch, up to the point of bad code making it into production. It’s definitely something GitLab should change their thinking on.