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

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

Branches (FREE)

A branch is a version of a project's working tree. You create a branch for each set of related changes you make. This keeps each set of changes separate from each other, allowing changes to be made in parallel, without affecting each other.

After pushing your changes to a new branch, you can:

• Create a merge request. You can streamline this process by following branch naming patterns.
• Perform inline code review.
• Discuss your implementation with your team.
• Preview changes submitted to a new branch with Review Apps.

You can also request approval from your managers.

For more information on managing branches using the GitLab UI, see:

• Default branches: When you create a new project, GitLab creates a default branch for the repository. You can change this setting at the project, subgroup, group, or instance level.
• Create a branch
• Protected branches
• Delete merged branches
• Branch filter search box

You can also manage branches using the command line.

Watch the video GitLab Flow.

See also:

• Branches API, for information on operating on repository branches using the GitLab API.
• GitLab Flow documentation.
• Getting started with Git and GitLab.

Naming

Prefix a branch name with an issue number to streamline merge request creation. When you create a merge request for a branch with a name beginning with an issue number, GitLab:

• Marks the issue as related. If your project is configured with a default closing pattern, merging this merge request also closes the related issue.
• Copies label and milestone metadata from the issue.

Compare

To compare branches in a repository:

1. Navigate to your project's repository.

2. Select Repository > Compare in the sidebar.

3. Select the target repository to compare with the repository filter search box.

4. Select branches to compare using the branch filter search box.

5. Select Compare to view the changes inline:

   

Delete merged branches

This feature allows merged branches to be deleted in bulk. Only branches that have been merged into the project's default branch and are not protected are deleted as part of this operation.

It's particularly useful to clean up old branches that were not deleted automatically when a merge request was merged.

Repository filter search box

Introduced in GitLab 13.10.

This feature allows you to search and select a repository quickly when comparing branches.

Search results appear in the following order:

• Repositories with names exactly matching the search terms.
• Other repositories with names that include search terms, sorted alphabetically.

Branch filter search box

This feature allows you to search and select branches quickly. Search results appear in the following order:

• Branches with names that matched search terms exactly.
• Other branches with names that include search terms, sorted alphabetically.

Sometimes when you have hundreds of branches you may want a more flexible matching pattern. In such cases you can use the following operators:

• ^ matches beginning of branch name, for example ^feat would match feat/user-authentication
• $ matches end of branch name, for example widget$ would match feat/search-box-widget
• * wildcard matcher, for example branch*cache* would match fix/branch-search-cache-expiration

These operators can be mixed, for example ^chore/*migration$ would match chore/user-data-migration

Swap revisions

Introduced in GitLab 13.12.

The Swap revisions feature allows you to swap the Source and Target revisions. When the Swap revisions button is selected, the selected revisions for Source and Target is swapped.

View branches with configured protections (FREE SELF)

Introduced in GitLab 15.1 with a flag named branch_rules. Disabled by default.

FLAG: On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to enable the feature flag named branch_rules. On GitLab.com, this feature is not available. This feature is not ready for production use.

Branches in your repository can be protected by limiting who can push to a branch, require approval for those pushed changes, or merge those changes. To help you track the protections for all branches, the Branch rules overview page shows your branches with their configured rules.

To view the Branch rules overview list:

1. On the top bar, select Main menu > Projects and find your project.
2. On the left sidebar, select Settings > Repository.
3. Expand Branch Rules to view all branches with protections.
4. Select Details next to your desired branch to show information about its:
   • Branch protections.
   • Approval rules.
   • Status checks.

Troubleshooting

Multiple branches containing the same commit

At a deeper technical level, Git branches aren't separate entities, but labels attached to a set of commit SHAs. When GitLab determines whether or not a branch has been merged, it checks the target branch for the existence of those commit SHAs. This behavior can cause unexpected results when two merge requests contain the same commits. In this example, branches B and C both start from the same commit (3) on branch A:

gitGraph
    commit id:"a"
    branch "branch A"
    commit id:"b"
    commit id:"c" type: HIGHLIGHT
    branch "branch B"
    commit id:"d"
    checkout "branch A"
    branch "branch C"
    commit id:"e"
    checkout main
    merge "branch B" id:"merges commits b, c, d"

If you merge branch B, branch A also appears as merged (without any action from you) because all commits from branch A now appear in the target branch main. Branch C remains unmerged, because commit 5 wasn't part of branch A or B.

Merge request A remains merged, even if you attempt to push new commits to its branch. If any changes in merge request A remain unmerged (because they weren't part of merge request A), open a new merge request for them.

Error: ambiguous HEAD branch exists

In versions of Git earlier than 2.16.0, you could create a branch named HEAD. This branch named HEAD collides with the internal reference (also named HEAD) Git uses to describe the active (checked out) branch. This naming collision can prevent you from updating the default branch of your repository:

Error: Could not set the default branch. Do you have a branch named 'HEAD' in your repository?

To fix this problem:

1. On the top bar, select Main menu > Projects and find your project.
2. On the left sidebar, select Repository > Branches.
3. Search for a branch named HEAD.
4. Make sure the branch has no uncommitted changes.
5. Select Delete branch, then Yes, delete branch.

Git versions 2.16.0 and later, prevent you from creating a branch with this name.