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.

Answer 1

Setting -> Repository -> Branch defaults

Answer 2

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.

---

You cal also combine that with GitLab 16.6 (November 2023):

Minimal forking - only include the default branch

In previous versions of GitLab, when forking a repository, the fork always included all branches within the repository. Now you can create a fork with only the default branch, reducing complexity and storage space. Create minimal forks if you don’t need the changes that are currently being worked on in other branches.

The default method of forking will not change and continue to include all branches within the repository. The new option shows which branch is the default, so that you are aware of exactly which branch will be included in the new fork.

See Documentation and Issue.

Answer 3

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.

Answer 4

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.

Answer 5

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

Enjoy！

Answer 6

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.