How to change the default target branch for merges in Gitlab

Question

we are using Gitlab 8.10.1 with many groups and projects. Many of the projects happen to be forks of other projects. Our problem is that whenever somebody opens a merge request for a project the default target branch is NOT the default branch of the project but from one very specific other project. Is there a way to override this setting somehow? Just to make it clear, I know how to set the default branch of a project and those settings appear to be correct, however gitlab doesn't seem to use them when creating merge requests. This issue is very annoying and has led to weird situations when people didn't pay attention and made merge requests with a completely different "master" as target.

Solution 1

The default MR target depends on whether or not the repository is a GitLab fork.

Forks

If the repository is a GitLab fork, then the default MR target will be the default branch of the upstream repository. This relationship can be removed via the "Remove fork relationship" option on the Project settings page, after which the default MR target will be determined as normal for a non-fork repository (described below).

At time of writing, it is not possible to override the default MR target without removing the fork relationship, but that functionality has been requested in gitlab issue #14522.

Non-Forks

If the repository has no fork relationship, then the Default Branch setting on the Project settings page sets both (1) the default MR target, and (2) the HEAD reference of the repo on the GitLab server (which determines the branch that's checked out when the repo is cloned). Note that, due to a bug/quirk in git, problems can occur if a branch that was once the Default Branch is later deleted from GitLab.

At time of writing, it is not possible to change the default MR target independently of the Default Branch, but this functionality has been requested in gitlab issue #17909.

Solution 2

you need master。 Then Project setting---Default Branch ---save change

Enjoy！

Solution 3

As of version 11.5.3 the settings changed a bit. From docs.gitlab.com:

When you create a new project, GitLab sets master as the default branch for your project. You can choose another branch to be your project’s default under your project’s Settings > Repository.

Solution 4

We found the source for this behavior, it is due to the relationship between the projects as one project was forked in gitlab from the other. When removing the relation between the source and the fork, the default branch for merges is the default branch of the project itself. Right now this is our solution for this situation, as we can live with the implications of the removal of the source<->fork relation.

Solution 5

Regarding forks, there is an interesting feature coming with GitLab 13.11 (April 2021)

Set default target project for merge requests in forks

After forking a project, it can be beneficial to use merge requests to make contributions to the upstream project.

Previously, GitLab assumed that merge requests from your fork project would always target the upstream project.
This can create missteps where code shouldn’t be merged upstream, or users need to make changes prior to opening the merge request.

GitLab now supports setting the default target project for merge requests that are created in fork projects.
This streamlines contributions and helps avoid mistakes for users and teams who more commonly contribute to their fork project, instead of the upstream project.

See Documentation and Issue.

View more solutions

Comments

[NindzAI]

It would be more useful if you could list the steps to do this.

[Jordan Whitfield]

but beware that this will change the default branch used when cloning

[komidawi]

Good news! Functionality for changing default target for GitLab forks finally has been added! Issue #14522 is now closed :)

[David P]

Thanks @komidawi. Unfortunately that only allows for changing the default target project, not the default target branch, but we're halfway there. Hopefully they'll get on to implementing #17909 soon.