SONAR-12708 Update docs for single branch concept

13 files changed, 68 insertions, 141 deletions

diff --git a/server/sonar-docs/src/EmbedDocsSuggestions.json b/server/sonar-docs/src/EmbedDocsSuggestions.json
index 9260268131c..aeca5c1a53a 100644
--- a/server/sonar-docs/src/EmbedDocsSuggestions.json
+++ b/server/sonar-docs/src/EmbedDocsSuggestions.json
@@ -93,7 +93,7 @@
     },
     {
       "link": "/documentation/branches/overview/",
-      "text": "Branches Overview"
+      "text": "Branches Analysis"
     },
     {
       "link": "/documentation/analysis/pull-request/",
diff --git a/server/sonar-docs/src/pages/analysis/overview.md b/server/sonar-docs/src/pages/analysis/overview.md
index 8837d6ee075..78953578526 100644
--- a/server/sonar-docs/src/pages/analysis/overview.md
+++ b/server/sonar-docs/src/pages/analysis/overview.md
@@ -67,7 +67,7 @@ By default, only files that are recognized by a language analyzer are loaded int
 For example if your SonarQube instance had only SonarJava SonarJS on board, all .java and .js files would be loaded, but .xml files would be ignored.
 
 ## What about branches and pull requests?
-_Developer Edition_ adds the ability to analyze your project's release / [long-lived branches](/branches/long-lived-branches/), feature / [short-lived branches](/branches/short-lived-branches/), and [pull requests](/analysis/pull-request/) as well as the ability to automatically decorate pull requests in some SCM interfaces. For more on branches see the [branches overview](/branches/overview/).
+_Developer Edition_ adds the ability to analyze your project's [branches](/branches/overview/) and [pull requests](/analysis/pull-request/) as well as the ability to automatically decorate pull requests in some ALM interfaces. 
 <!-- /sonarqube -->
 
 ## What happens during analysis?
diff --git a/server/sonar-docs/src/pages/analysis/pull-request.md b/server/sonar-docs/src/pages/analysis/pull-request.md
index 498162d58d2..c6712519a87 100644
--- a/server/sonar-docs/src/pages/analysis/pull-request.md
+++ b/server/sonar-docs/src/pages/analysis/pull-request.md
@@ -30,4 +30,4 @@ These parameters enable PR analysis:
 | --------------------- | ---------------------------------- |
 | `sonar.pullrequest.key` | Unique identifier of your PR. Must correspond to the key of the PR in GitHub or Azure DevOps.<br/> e.g.: `sonar.pullrequest.key=5` |
 | `sonar.pullrequest.branch` | The name of the branch that contains the changes to be merged.<br/> e.g.: `sonar.pullrequest.branch=feature/my-new-feature` |
-| `sonar.pullrequest.base` | The long-lived branch into which the PR will be merged. <br/> Default: master <br/> e.g.: `sonar.pullrequest.base=master` |
+| `sonar.pullrequest.base` | The branch into which the PR will be merged. <br/> Default: master <br/> e.g.: `sonar.pullrequest.base=master` |
diff --git a/server/sonar-docs/src/pages/branches/branches-faq.md b/server/sonar-docs/src/pages/branches/branches-faq.md
index 009839e4516..9b7adeab9e8 100644
--- a/server/sonar-docs/src/pages/branches/branches-faq.md
+++ b/server/sonar-docs/src/pages/branches/branches-faq.md
@@ -1,31 +1,21 @@
 ---
-title: Frequently Asked Branches Questions
+title: Branch FAQ
 url: /branches/branches-faq/
 ---
 
-<!-- sonarqube -->
-
 _Branch analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and [above](https://www.sonarsource.com/plans-and-pricing/)._
 
-<!-- /sonarqube -->
-
-
 ## How long are branches retained?  
-Long-lived branches are retained until you delete them manually (**Administration > Branches**).
-Short-lived branches are deleted automatically after 30 days with no analysis.
-This can be updated in **Configuration > General > Number of days before purging inactive short living branches**. For more, see [Housekeeping](/instance-administration/housekeeping/).
+Branches will be deleted automatically when they are inactive according to your settings at [Administration > Configuration > General Settings > Housekeeping > Number of days before deleting inactive branches](/#sonarqube-admin#/admin/settings?category=housekeeping) except for branches you have set to be kept when inactive. These branches are kept until you delete them manually at the project level at **Administration > Branches & Pull Requests**. See the [Branches Analysis](/branches/overview/) for more information on keeping inactive branches.
 
 ## Does my project need to be stored in an SCM like Git or SVN?  
 No, you don't need to be connected to a SCM. But if you use Git or SVN we can better track the new files on short-lived branches and so better report new issues on the files that really changed during the life of the short-lived branch.
 
 ## What if I mark an Issue "Won't Fix" or "False-Positive" in a branch?
-It be replicated as such when merging my short-lived branch into the Master. Each time there is an analysis of a long-lived branch, we look at the issues on the short-lived branches and try to synchronize them with the newly raised issues on the long-lived branch. In case you made some changes on the issues (false-positive, won't fix), these changes will be reported on the long-lived branch.
+It will be replicated as such when creating a Pull Request and merging the Pull Request into the master branch.
 
 ## Can I manually delete a branch?  
-This can be achieved by going into the Administration menu at Project's level, then Branches.
-
-## How do I control the lifespan of a short-lived branch?  
-As a global admin, you can set the parameter `sonar.dbcleaner.daysBeforeDeletingInactiveShortLivingBranches` to control how many days you want to keep an inactive short-lived branch.
+You can delete a branch in the **Branches** tab at **Project Settings > Branches and Pull Requests**.
 
 ## Does the payload of the Webhook include branch information?  
 Yes, an extra node called "branch" is added to the payload.
diff --git a/server/sonar-docs/src/pages/branches/long-lived-branches.md b/server/sonar-docs/src/pages/branches/long-lived-branches.md
deleted file mode 100644
index b1cdaf2e22c..00000000000
--- a/server/sonar-docs/src/pages/branches/long-lived-branches.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-title: Long-lived Branches
-url: /branches/long-lived-branches/
----
-
-<!-- sonarqube -->
-
-_Branch analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and [above](https://www.sonarsource.com/plans-and-pricing/)._
-
-<!-- /sonarqube -->
-
-## Status vs Quality Gate
-
-The same quality gate that is applied to the project as a whole is automatically applied to long-lived branches as well. This is not editable.
-
-## Issue Creation and Synchronization
-
-During the **first analysis only**, 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 long-lived branch: "The issue has been copied from branch 'master' to branch yyy".
-
-Then, at each subsequent analysis of the long-lived branch, any new issue that comes from a short-lived branch automatically inherits the attributes (type, severity, ...) the issue had in the short-lived branch. A comment is added to the change log of the issue on the long-lived branch: "The issue had been copied from branch 'the short-live branch' to branch yyy".
-
-## New Code Period
-
-Because long-lived branches will persist for a long time, you are likely to develop and release multiple versions from it, and so you can change the New Code period of a long-lived branch in **Administration > Branches**.
-
-## Settings and Quality Profiles on Branches
-
-Branch settings and quality profiles default to those set for the master branch, and by design, it's not possible to configure other values.
diff --git a/server/sonar-docs/src/pages/branches/overview.md b/server/sonar-docs/src/pages/branches/overview.md
index 3d4e4ed6eee..bc8d1d79d37 100644
--- a/server/sonar-docs/src/pages/branches/overview.md
+++ b/server/sonar-docs/src/pages/branches/overview.md
@@ -1,79 +1,80 @@
 ---
-title: Overview
+title: Branch Analysis
 url: /branches/overview/
 ---
 
-<!-- sonarqube -->
 _Branch analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and [above](https://www.sonarsource.com/plans-and-pricing/)._
-<!-- /sonarqube -->
 
+## Overview
 
-Branch analysis allows you to
+With Branch Analysis, you can ensure that you're maintaining consistent code quality all the way down to the branch level of your projects. 
 
-* analyze long-lived branches
-* analyze short-lived branches
-* notify external systems when the status of a short-lived branch is impacted
+### Master / Main Branch
 
-## Branch Types
+This is the default branch and typically corresponds to what's being developed for your next release. This is usually known within a development team as "master" or "head" and is analyzed when no specific branch parameters are provided. It is labeled "Main Branch" and defaults to the name "master" but can be renamed from the project settings at **Administration > Branches and Pull Requests**. When you are using Community Edition, this is the only branch you see.
 
-### Short-lived
+### Settings and Quality Profiles on Branches
 
-This corresponds to Pull/Merge Requests or Feature Branches. This kind of branch:
+Branch settings and quality profiles are the same as those set for the master branch, and by design, it's not possible to configure other values. The New Code Period is the only exception to this as it can be set on a branch-by-branch basis. 
 
-* will disappear quickly
-* will be merged rapidly to prevent integration issues
-* is developed for a given version, so the version does not change,
-  and there is no way to set the New Code period; everything that has been changed in the branch is new code
-* tracks all the new issues related to the code that changed on it.
+### New Code Period
 
-![conceptual illustration of short-lived branches.](/images/short-lived-branch-concept.png)
+You can set a New Code Period for each branch. This is especially helpful if you are likely to develop and release multiple versions from the branch. See the [New Code Period](/project-administration/new-code-period/) documentation for more information on setting a New Code Period.
 
-For more, see [Short-lived Branches](/branches/short-lived-branches/)
+### Quality Gate
 
-### Long-lived
+The branch Quality Gate lets you know if your branch is ready to be merged. Each branch has a quality gate that:
 
-This corresponds to "Maintenance" Branches that will house several release versions.
-This kind of branch will:
+* Applies on conditions on New Code and overall code.
+* Assigns a status (Passed or Failed).
 
-* last for a long time
-* inevitably diverge more and more from the other branches
-* house several release versions, each of which must pass the quality gate
-  to go to production not be expected to be merged into another branch
+## Setting up Branch analysis
 
-![conceptual illustration of long-lived branches.](/images/long-lived-branch-concept.png)
+A branch is created when the `sonar.branch.name` parameter is passed during analysis.
 
-For more, see [Long-lived Branches](/branches/long-lived-branches/)
+| Parameter Name        | Description |
+| --------------------- | ------------------------------------------------- |
+| `sonar.branch.name`   | Name of the branch (visible in the UI)
 
-### Master / Main Branch
+### Limiting analysis to relevant branches  
 
-This is the default, and typically corresponds to what's being developed for
-your next release. This is usually known within a development team as
-"master" or "head", and is what is analyzed when no specific branch parameters
-are provided. It is labeled "Main Branch" and defaults to the name "master",
-but can be renamed from within the interface. When you are not using Developer Edition, this is the only branch you see.
+You need to add a condition to your pipeline script to ensure only 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 . 
 
-## Analysis
+In the following example, analysis would be limited to branches named `master` or `release/*`.
 
-A branch is created when the `sonar.branch.name` parameter is passed during analysis.
+```
+if [[ "$CI_BRANCH_NAME" == master ]] || [[ "$CI_BRANCH_NAME" == release/* ]]; then
+  ./gradlew sonarqube
+fi
+``` 
+
+### Issue Creation and Synchronization
+
+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 'master' to branch yyy".
+
+At each subsequent analysis of the branch, any new issue that comes from a pull request automatically inherits the attributes (type, severity, ...) the issue had in the pull request. A comment is added to the change log of the issue on the branch: "The issue has been merged from 'xxx' into 'yyy'"
+
+### Fetching full Git history
+
+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
+Inactive branches are branches that are no longer being analyzed. You can use Housekeeping 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
 
-| Parameter Name        | Description                                                                                                                                                                                                                                                             |
-| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `sonar.branch.name`   | Name of the branch (visible in the UI)                                                                                                                                                                                                                                  |
-| `sonar.branch.target` | Name of the branch where you intend to merge your short-lived branch at the end of its life. If left blank, this defaults to the master branch. It can also be used while initializing a long-lived branch to sync the issues from a branch other than the Main Branch. |
+You can set the number of days a branch can be inactive before it's deleted at **Administration > Housekeeping > Number of days before deleting inactive branches**. Branches that are inactive for the number of days that you set will be automatically deleted.
 
-### Git History
+### Using patterns to keep inactive branches
 
-By default, 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.
+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 > Housekeeping > Branches > Branches to keep when inactive**. When a branch is created with a name that follows one of these patterns, it will be kept indefinitely. 
 
-### Configuring the Branch type
+For example, adding the pattern `release/.*` would keep any branches named release/6.0, release/7, and so on.
 
-A regular expression is used to determine whether a branch is treated as long-lived or short-lived. By default, branches that have names starting with either "branch" or "release" will be treated as long-lived.
+**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.
 
-This can be updated <!-- sonarqube -->globally in **Configuration > General Settings > General > Detection of long-lived branches** or <!-- /sonarqube -->at a project's level in **Admininstration > Branches & Pull requests**.
+### Managing inactive branches at a project level
 
-Once a branch type has been set, it cannot be changed. Explicitly, you cannot transform a long-lived to short-lived branch, or vice-versa.
+You can set a branch to **Keep when inactive** at the project level from from the **Branches** tab at **Administration > 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 specified at **Administration > Housekeeping > Number of days before deleting inactive branches**. 
 
-## See also
-* [Short-lived Branches](/branches/short-lived-branches/)
-* [Long-lived Branches](/branches/long-lived-branches/)
-* [Frequently Asked Questions](/branches/branches-faq/)
+**Note:** The main branch is always protected from automatic deletion, even if it's inactive. This can't be changed.
\ No newline at end of file
diff --git a/server/sonar-docs/src/pages/branches/short-lived-branches.md b/server/sonar-docs/src/pages/branches/short-lived-branches.md
deleted file mode 100644
index 3ffa32ad003..00000000000
--- a/server/sonar-docs/src/pages/branches/short-lived-branches.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: Short-lived Branches
-url: /branches/short-lived-branches/
----
-
-<!-- sonarqube -->
-
-_Branch analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and [above](https://www.sonarsource.com/plans-and-pricing/)._
-
-<!-- /sonarqube -->
-
-Short-lived branch analysis shows your analysis and quality gate status in the {instance} UI.
-
-## Quality Gate
-
-The short-lived branch quality gate:
-
-* **Focuses on new code** – The short-lived branch quality gate only uses your project's quality gate conditions that apply to "on New Code" metrics.
-* **Assigns a status** – Each short-lived branch shows a quality gate status reflecting whether it Passed (green) or Failed (red).
-
-## Issue Creation and Synchronization
-
-The issues visible on the short-lived branch are the new issues corresponding to files modified in the branch.
-
-Modified files are determined based on the checksum of each file on the sonar.branch.target and the short-lived branch.
-
-## New Code Period
-
-The ephemeral nature of short-lived branches means the New Code Period is implicit; everything changed in the branch is new code.
-
-## Settings and Quality Profiles on Branches
-
-Branch settings and quality profiles default to those set for the master branch, and by design, it's not possible to configure other values.
-
-## Known Limitations
-
-* You cannot connect SonarLint to a short-lived branch.
-* Analysis of a short-lived branch based on another short-lived branch is not supported.
diff --git a/server/sonar-docs/src/pages/faq.md b/server/sonar-docs/src/pages/faq.md
index 3fa570d163d..ce277ade95d 100644
--- a/server/sonar-docs/src/pages/faq.md
+++ b/server/sonar-docs/src/pages/faq.md
@@ -5,7 +5,7 @@ url: /faq/
 
 ## How do I get rid of issues that are False-Positives?
 **False-Positive and Won't Fix**  
-You can mark individual issues False Positive or Won't Fix through the issues interface. If you're using Short-lived branch and PR analysis provided by the Developer Edition, issues marked False Positive or Won't Fix will retain that status after merge. This is the preferred approach.
+You can mark individual issues False Positive or Won't Fix through the issues interface. If you're using PR analysis provided by the Developer Edition, issues marked False Positive or Won't Fix will retain that status after merge. This is the preferred approach.
 
 **//NOSONAR**  
 Most language analyzers support the use of the generic mechanism: `//NOSONAR` at the end of the line of the issue. This will suppress the all issues - now and in the future - that might be raised on the line.
diff --git a/server/sonar-docs/src/pages/project-administration/configuring-portfolios-and-applications.md b/server/sonar-docs/src/pages/project-administration/configuring-portfolios-and-applications.md
index ec926b1dcda..256b13baf09 100644
--- a/server/sonar-docs/src/pages/project-administration/configuring-portfolios-and-applications.md
+++ b/server/sonar-docs/src/pages/project-administration/configuring-portfolios-and-applications.md
@@ -48,7 +48,7 @@ To add an Application to a Portfolio, first make sure your Application is [alrea
 Once your Application exists, you can populate it with manually-selected projects. By default, the configuration interface shows the list of projects currently selected for the application. To add additional projects, choose the "Unselected" or "All" filter.
 
 ## Creating Application Branches
-Once your Application is populated with projects, you can create application branches by choosing long-lived branches from the application's component projects. This option is available in the Application's **Administration > Edit Definition** interface, or from the global administration interface.
+Once your Application is populated with projects, you can create application branches by choosing branches from the application's component projects. This option is available in the Application's **Administration > Edit Definition** interface, or from the global administration interface.
 
 ## Calculation
 By default, Applications and Portfolios are queued to be recalculated after each analysis of an included project. For each relevant Portfolio and Application, a “Background Task” is created, and you can follow the progress on each in the **[Administration > Projects > Background Tasks](/#sonarqube-admin#/admin/background_tasks)** by looking at the logs available for each item.
diff --git a/server/sonar-docs/src/pages/project-administration/narrowing-the-focus.md b/server/sonar-docs/src/pages/project-administration/narrowing-the-focus.md
index 286a48d6bf9..59e04475a80 100644
--- a/server/sonar-docs/src/pages/project-administration/narrowing-the-focus.md
+++ b/server/sonar-docs/src/pages/project-administration/narrowing-the-focus.md
@@ -12,7 +12,7 @@ If {instance}'s results aren't relevant, no one will want to use it. That's why
 * exclude files/directories from Duplications detection but analyze all other aspects
 * exclude files/directories from Coverage calculations but analyze all other aspects
 
-You can make these changes globally or at a project level. At both levels, the navigation path is the same: **Administration > General Settings > Analysis Scope**.
+You can make these changes globally or at a project level. At both levels, the navigation path is  **Administration > General Settings > Analysis Scope**.
 
 ## Patterns
 
@@ -127,7 +127,7 @@ PATH #2 = `bank/bankcard/**/*`
 
 You can prevent some files from being checked for duplications.
 
-To do so, go to **Administration > General Settings > Analysis Scope > Duplications** and set the *Duplication Exclusions* property. See the Patterns section for more details on the syntax.
+To do so, go to [Administration > General Settings > Analysis Scope > Duplications](/#sonarqube-admin#/admin/settings) and set the *Duplication Exclusions* property. See the Patterns section for more details on the syntax.
 
 ## Ignore Code Coverage
 
diff --git a/server/sonar-docs/src/pages/project-administration/new-code-period.md b/server/sonar-docs/src/pages/project-administration/new-code-period.md
index 55575babe6d..f4887b179b1 100644
--- a/server/sonar-docs/src/pages/project-administration/new-code-period.md
+++ b/server/sonar-docs/src/pages/project-administration/new-code-period.md
@@ -23,11 +23,11 @@ You can set a project's New Code Period to the following:
 * **Number of days** – Specify a number of days for a floating New Code Period. For example, setting **Number of Days** to 30 creates a floating New Code Period beginning 30 days from the current date.
 * **Specific analysis** – Choose a previous analysis as your New Code Period. The New Code Period will show any changes made since that analysis. 
 
-   **Note:** For Community Edition, you can set the New Code Period to a specific past analysis at the project-level because Community Edition doesn't support multiple branches. [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and [above](https://www.sonarsource.com/plans-and-pricing/) let you set the New Code Period to a specific analysis at the branch level. Each long-lived branch can be set to one of the branch's specific past analyses. See the following section for information on setting a branch-level New Code Period. 
+   **Note:** For Community Edition, you can set the New Code Period to a specific past analysis at the project-level because Community Edition doesn't support multiple branches. [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and [above](https://www.sonarsource.com/plans-and-pricing/) let you set the New Code Period to a specific analysis at the branch level. Each branch can be set to one of the branch's specific past analyses. See the following section for information on setting a branch-level New Code Period. 
 
 ### Setting a branch-level New Code Period
 _Branch analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and [above](https://www.sonarsource.com/plans-and-pricing/)._  
-For projects with multiple long-lived branches, you can set a New Code Period for each branch from the **Actions** column of the branches table on the project's **New Code Period** settings page.
+For projects with multiple branches, you can set a New Code Period for each branch from the **Actions** column of the branches table on the project's **New Code Period** settings page.
 
 You can set a branch's New Code Period to the following:
 
diff --git a/server/sonar-docs/src/pages/project-administration/project-settings.md b/server/sonar-docs/src/pages/project-administration/project-settings.md
index 45ff2b93f84..3988ef4bd31 100644
--- a/server/sonar-docs/src/pages/project-administration/project-settings.md
+++ b/server/sonar-docs/src/pages/project-administration/project-settings.md
@@ -38,14 +38,14 @@ The new key must contain at least one non-digit character. Allowed characters ar
 
 ### Default Issue Assignee
 
-When new issues are created during an analysis, they are assigned to the last committer where the issue was raised. When it is not possible to identify the last committer, issues can be assigned to a default assignee, at **Administration > General Settings > Issues**.
+When new issues are created during an analysis, they are assigned to the last committer where the issue was raised. When it is not possible to identify the last committer, issues can be assigned to a default assignee, at ]Administration  > General Settings > Issues](/#sonarqube-admin#/admin/settings).
 
 ### Setting Quality Gate and Quality Profiles  
 
 Project administrators can select which ...
 
-* Quality profiles (go to **Administration > Quality Profiles**)
-* Quality gate (go to **Administration > Quality Gate**)
+* Quality profiles (go to **Administration  > Quality Profiles**)
+* Quality gate (go to **Administration  > Quality Gate**)
 
 ... to use on their project.
 
diff --git a/server/sonar-docs/src/pages/user-guide/applications.md b/server/sonar-docs/src/pages/user-guide/applications.md
index bcec6ad7177..2cecad1a61c 100644
--- a/server/sonar-docs/src/pages/user-guide/applications.md
+++ b/server/sonar-docs/src/pages/user-guide/applications.md
@@ -23,6 +23,8 @@ An Application is automatically re-calculated after each analysis of one of its
 
 ## Applications and Branch Analysis
 
-Long-lived Branches are available for applications. They allow you to aggregate long-lived branches from the projects in an application.
+Branches are available for Applications. They allow you to aggregate branches from the projects in an Application.
+
+**Note:** Avoid adding branches to your application that will be deleted to prevent issues with your Application status.
 
 Once an Application has been set up, anyone with administration rights on the Application can manually create a new branch in the **Administration > Edit Definition** interface. Branches can also be managed from the global **Administration > Configuration > Portfolios** interface. For each Application branch you can choose which project branch should be included, or whether the project should be represented in the branch at all.