# Branch analysis

*Branch analysis is available starting in* [*Developer Edition*](https://www.sonarsource.com/plans-and-pricing/developer/)*.*

## Overview <a href="#overview" id="overview"></a>

With branch analysis, you can ensure that you’re maintaining consistent code quality all the way down to the branch level of your projects.

## Main branch <a href="#main-branch" id="main-branch"></a>

This is the default branch and typically corresponds to what’s being developed for your next release. This branch is usually known within a development team as "main", "develop" or "head" and is analyzed when no specific branch parameters are provided. SonarQube labels this branch as **Main Branch**, and, with Community Edition, this is the only branch you can analyze.

Adding projects by DevOps Platform copies the main branch name in SonarQube from the main branch name in your repository. See **DevOps Platform Integrations** in the documentation navigation for more information on adding your project from an DevOps Platform.

If you add your project manually, your main branch defaults to the name `main`.

Starting in [*Developer Edition*](https://www.sonarsource.com/plans-and-pricing/developer/), your main branch can be renamed from the project settings at **Project Settings** > **Branches and Pull Requests**.

### Settings and quality profiles on branches <a href="#settings-and-quality-profiles-on-branches" id="settings-and-quality-profiles-on-branches"></a>

Branch settings and quality profiles are the same as those set for the main branch, and by design, it’s not possible to configure other values. The new code definition is the only exception to this as it can be set on a branch-by-branch basis.

### New code <a href="#new-code" id="new-code"></a>

You can set a new code definition for each branch. This is especially helpful if you are likely to develop and release multiple versions from the branch. See the [defining-new-code](https://docs.sonarsource.com/sonarqube-server/10.0/project-administration/defining-new-code "mention") documentation for more information, and review [clean-as-you-code](https://docs.sonarsource.com/sonarqube-server/10.0/user-guide/clean-as-you-code "mention") for guidance on focusing on new code.

### Quality gate <a href="#quality-gate" id="quality-gate"></a>

The branch quality gate lets you know if your branch is ready to be merged. Each branch has a quality gate that:

* Applies to conditions on new code and overall code.
* Assigns a status (passed or failed).

## Setting up branch analysis <a href="#branch-analysis" id="branch-analysis"></a>

A branch is created when the `sonar.branch.name` parameter is passed during analysis.

{% hint style="info" %}
Scanners can automatically detect branch parameters when running on the following CI services:

* Azure Pipelines
* Bitbucket Pipelines
* Cirrus CI
* Codemagic
* GitHub Actions
* GitLab CI/CD
* Jenkins (with the Branch Source plugin configured)

Manually setting branch parameters overrides automatic detection.
{% endhint %}

|                     |                                        |
| ------------------- | -------------------------------------- |
| **Parameter Name**  | **Description**                        |
| `sonar.branch.name` | Name of the branch (visible in the UI) |

### Limiting analysis to relevant branches <a href="#limiting-analysis-to-relevant-branches" id="limiting-analysis-to-relevant-branches"></a>

You need to add a condition to your pipeline script to ensure that only the relevant branches are analyzed. For example, you wouldn’t want to run analysis on feature branches that won’t need analysis until they have pull requests.

In the following example, analysis would be limited to branches named `main` or `release/*`.

```css-79elbk
if [[ "$CI_BRANCH_NAME" == main ]] || [[ "$CI_BRANCH_NAME" == release/* ]]; then
  ./gradlew sonarqube
fi
```

### Issue Creation and Synchronization <a href="#issue-creation-and-synchronization" id="issue-creation-and-synchronization"></a>

During the first analysis, issues (type, severity, status, assignee, change log, comments) are synchronized with the main branch. In each synchronized issue, a comment is added to the change log of the issue on the branch: `The issue has been copied from branch 'main' to branch '<branch>'.`

At each subsequent analysis of the branch, any new issue in the main branch that comes from a pull request automatically inherits its attributes (type, severity, etc.) from the pull request. A comment is added to the change log of the issue on the branch: `The issue has been merged from '<branch-1>' into '<branch-2>'`

Issues can be synchronized between branches if you’re using the **Reference Branch** [Defining New Code](https://app.gitbook.com/s/Bmptmznn7RpPe5u7vdup/project-administration/defining-new-code "mention"). When using this new code definition, any new issue in the reference branch that comes from a feature branch automatically inherits its attributes (type, severity, etc.) from the feature branch. A comment is added to the change log of the issue on the branch: `The issue has been merged from '<branch-1>' into '<branch-2>`.

### Fetching full Git history <a href="#fetching-full-git-history" id="fetching-full-git-history"></a>

By default, some CIs don’t fetch your full Git history. For example, TravisCI only fetches the last 50 git commits. You must use `git fetch --unshallow` to get the full history. If you don’t, new issues may not be assigned to the correct developer.

## Managing inactive branches <a href="#inactive-branches" id="inactive-branches"></a>

Projects and branches that are not scanned for more than seven consecutive days are considered inactive, and SonarQube automatically deletes their cached data to free space in the database.

If a project has several branches, only the cache of its inactive branches is deleted after seven days.

You can use [housekeeping](https://docs.sonarsource.com/sonarqube-server/10.0/instance-administration/housekeeping "mention") to automatically delete branches that are inactive (i.e. old feature branches) or to keep inactive branches that you want to continue maintaining (i.e. release branches).

### Deleting inactive branches <a href="#deleting-inactive-branches" id="deleting-inactive-branches"></a>

You can set the number of days a branch can be inactive before it’s deleted in the global settings at **Administration** > **General Settings** > **Housekeeping** > **Number of days before deleting inactive branches**. Branches that are inactive for the number of days that you set will be automatically deleted.

### Using patterns to keep inactive branches <a href="#using-patterns-to-keep-inactive-branches" id="using-patterns-to-keep-inactive-branches"></a>

You can use naming patterns to protect specific branches, such as release branches, from automatic deletion. To do this, add a pattern using Java regular expressions under **Administration** > **General Settings** > **Housekeeping** > **Branches** > **Branches to keep when inactive** at either the global or project level. When a branch is created with a name that follows one of these patterns, it will be kept indefinitely.

For example, adding the pattern `release/.*` would keep any branches named `release/6.0`, `release/7`, and so on.

**Note:** Patterns aren’t retroactive and won’t apply to branches that have already been created. They only apply to branches created after the pattern is set. You can protect an existing branch at the project level. See the following section.

### Managing inactive branches at a project level <a href="#managing-inactive-branches-at-a-project-level" id="managing-inactive-branches-at-a-project-level"></a>

You can set a branch to **Keep when inactive** at the project level from the **Branches** tab at **Project Settings** > **Branches and Pull Requests**. Here, you can also turn off protection for a branch so it will be deleted when it’s inactive for the number of days that have been specified in the global settings at **Administration** > **General Settings** > **Housekeeping** > **Number of days before deleting inactive branches**.

**Note:** The main branch is always protected from automatic deletion, even if it’s inactive. This can’t be changed.

## Keeping your main branch history when upgrading from Community Edition to a commercial edition <a href="#branch-history" id="branch-history"></a>

{% hint style="info" %}
If you added a SonarQube project from a DevOps platform instead of manually, the name of the main branch in SonarQube is copied from the name of the main branch in your repository, and you shouldn’t have any branch history issues when upgrading to a commercial edition.
{% endhint %}

When upgrading to a current commercial edition version, automatic branch and pull request configuration creates branches based on their names in your code repository. If the name of your main branch in SonarQube doesn’t match the branch’s name in your code repository, the history of your main branch won’t be taken on by the branch you analyze.

**Before running analysis**, you can keep your branch history by renaming the main branch in SonarQube with the name of the branch in your code repository at **Project Settings** > **Branches and Pull Requests**.

For example, if your main branch is named `main` in SonarQube but `develop` in your code repository, rename your main branch to `develop` in SonarQube.