debian-mirror-gitlab/doc/user/project/repository/branches/default.md

stage	group	info	type
Create	Source Code	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments	concepts, howto

Default branch (FREE)

When you create a new project, GitLab creates a default branch in the repository. A default branch has special configuration options not shared by other branches:

• It cannot be deleted.
• It's initially protected against forced pushes.
• When a merge request uses an issue closing pattern to close an issue, the work is merged into this branch.

The name of your new project's default branch depends on any instance-level or group-level configuration changes made by your GitLab administrator. GitLab checks first for specific customizations, then checks at a broader level, using the GitLab default only if no customizations are set:

1. A project-specific custom default branch name.
2. A subgroup-level custom default branch name.
3. A group-level custom default branch name.
4. An instance-level custom default branch name.
5. If no custom default branch name is set at any level, GitLab defaults to:
   • main: Projects created with GitLab 14.0 or later.
   • master: Projects created before GitLab 14.0.

In the GitLab UI, you can change the defaults at any level. GitLab also provides the Git commands you need to update your copy of the repository.

Change the default branch name for a project

To update the default branch name for an individual project:

1. Sign in to GitLab with at least the Maintainer role.
2. In the left navigation menu, go to Settings > Repository.
3. Expand Default branch, and select a new default branch.
4. Optional. Select the Auto-close referenced issues on default branch checkbox to close issues when a merge request uses a closing pattern.
5. Select Save changes.

API users can also use the default_branch attribute of the Projects API when creating or editing a project.

Change the default branch name for an instance or group

GitLab administrators can configure a new default branch name at the instance level or group level.

Instance-level custom initial branch name (FREE SELF)

• Introduced in GitLab 13.2 with a flag named global_default_branch_name. Enabled by default.
• Generally available in GitLab 13.12. Feature flag global_default_branch_name removed.

GitLab administrators of self-managed instances can customize the initial branch for projects hosted on that instance. Individual groups and subgroups can override this instance-wide setting for their projects.

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > Repository.
3. Expand Default initial branch name.
4. Change the default initial branch to a custom name of your choice.
5. Select Save changes.

Projects created on this instance after you change the setting use the custom branch name, unless a group-level or subgroup-level configuration overrides it.

Group-level custom initial branch name

Introduced in GitLab 13.6.

Users with at least the Owner role of groups and subgroups can configure the default branch name for a group:

1. Go to the group Settings > Repository.
2. Expand Default branch.
3. Change the default initial branch to a custom name of your choice.
4. Select Save changes.

Projects created in this group after you change the setting use the custom branch name, unless a subgroup configuration overrides it.

Protect initial default branches (FREE SELF)

GitLab administrators and group owners can define branch protections to apply to every repository's default branch at the instance level and group level with one of the following options:

• Not protected - Both developers and maintainers can push new commits and force push.
• Protected against pushes - Developers cannot push new commits, but are allowed to accept merge requests to the branch. Maintainers can push to the branch.
• Partially protected - Both developers and maintainers can push new commits, but cannot force push.
• Fully protected - Developers cannot push new commits, but maintainers can. No one can force push.

Instance-level default branch protection (FREE SELF)

This setting applies only to each repository's default branch. To protect other branches, you must either:

• Configure branch protection in the repository.
• Configure branch protection for groups.

Administrators of self-managed instances can customize the initial default branch protection for projects hosted on that instance. Individual groups and subgroups can override this instance-wide setting for their projects.

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > Repository.
3. Expand Default branch.
4. Select Initial default branch protection.
5. To allow group owners to override the instance's default branch protection, select Allow owners to manage default branch protection per group.
6. Select Save changes.

Prevent overrides of default branch protection (PREMIUM SELF)

Introduced in GitLab 13.0.

Instance-level protections for default branches can be overridden on a per-group basis by the group's owner. In GitLab Premium or higher, GitLab administrators can disable this privilege for group owners, enforcing the instance-level protection rule:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > Repository.
3. Expand the Default branch section.
4. Clear the Allow owners to manage default branch protection per group checkbox.
5. Select Save changes.

NOTE: GitLab administrators can still update the default branch protection of a group.

Group-level default branch protection (PREMIUM)

• Introduced in GitLab 12.9.
• Settings moved and renamed in GitLab 14.9.

Instance-level protections for default branch can be overridden on a per-group basis by the group's owner. In GitLab Premium or higher, GitLab administrators can enforce protection of initial default branches which locks this setting for group owners.

1. On the top bar, select Menu > Groups and find your group.
2. On the left sidebar, select Settings > Repository.
3. Expand Default branch.
4. Select Initial default branch protection.
5. Select Save changes.

Update the default branch name in your repository

WARNING: Changing the name of your default branch can potentially break tests, CI/CD configuration, services, helper utilities, and any integrations your repository uses. Before you change this branch name, consult with your project owners and maintainers. Ensure they understand the scope of this change includes references to the old branch name in related code and scripts.

When changing the default branch name for an existing repository, you should preserve the history of your default branch by renaming it, instead of creating a new branch. This example renames a Git repository's (example) default branch.

1. On your local command line, navigate to your example repository, and ensure you're on the default branch:

   cd example
   git checkout master
   

2. Rename the existing default branch to the new name (main). The argument -m transfers all commit history to the new branch:

   git branch -m master main
   

3. Push the newly created main branch upstream, and set your local branch to track the remote branch with the same name:

   git push -u origin main
   

4. If you plan to remove the old default branch, update HEAD to point to your new default branch, main:

   git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
   

5. Sign in to GitLab with at least the Maintainer role and follow the instructions to change the default branch for this project. Select main as your new default branch.

6. Protect your new main branch as described in the protected branches documentation.

7. Optional. If you want to delete the old default branch:

   1. Verify that nothing is pointing to it.

   2. Delete the branch on the remote:

      git push origin --delete master
      

      You can delete the branch at a later time, after you confirm the new default branch is working as expected.

8. Notify your project contributors of this change, because they must also take some steps:

   • Contributors should pull the new default branch to their local copy of the repository.
   • Contributors with open merge requests that target the old default branch should manually re-point the merge requests to use main instead.

9. In your repository, update any references to the old branch name in your code.

10. Update references to the old branch name in related code and scripts that reside outside your repository, such as helper utilities and integrations.

Default branch rename redirect

Introduced in GitLab 14.1

URLs for specific files or directories in a project embed the project's default branch name, and are often found in documentation or browser bookmarks. When you update the default branch name in your repository, these URLs change, and must be updated.

To ease the transition period, whenever the default branch for a project is changed, GitLab records the name of the old default branch. If that branch is deleted, attempts to view a file or directory on it are redirected to the current default branch, instead of displaying the "not found" page.

Related topics

• Configure a default branch for your wiki
• Discussion of default branch renaming on the Git mailing list
• March 2021 blog post: The new Git default branch name

Troubleshooting

Unable to change default branch: resets to current branch

We are tracking this problem in issue 20474. This issue often occurs when a branch named HEAD is present in the repository. To fix the problem:

1. In your local repository, create a new temporary branch and push it:

   git checkout -b tmp_default && git push -u origin tmp_default
   

2. In GitLab, proceed to change the default branch to that temporary branch.

3. From your local repository, delete the HEAD branch:

   git push -d origin HEAD
   

4. In GitLab, change the default branch to the one you intend to use.

Query GraphQL for default branches

You can use a GraphQL query to retrieve the default branches for all projects in a group.

To return all projects in a single page of results, replace GROUPNAME with the full path to your group. GitLab returns the first page of results. If hasNextPage is true, you can request the next page by replacing the null in after: null with the value of endCursor:

{
 group(fullPath: "GROUPNAME") {
   projects(after: null) {
     pageInfo {
       hasNextPage
       endCursor
     }
     nodes {
       name
       repository {
         rootRef
       }
     }
   }
 }
}