PUT /workspaces/{workspace}/projects/{project_key}/branching-model/settings
Update the branching model configuration for a project.
The development branch can be configured to a specific branch or to
track the main branch. Any branch name can be supplied, but will only
successfully be applied to a repository via inheritance if that branch
exists for that repository. Only the passed properties will be updated. The
properties not passed will be left unchanged. A request without a
development property will leave the development branch unchanged.
The production branch can be a specific branch, the main
branch or disabled. Any branch name can be supplied, but will only
successfully be applied to a repository via inheritance if that branch
exists for that repository. The enabled property can be used to enable (true)
or disable (false) it. Only the passed properties will be updated. The
properties not passed will be left unchanged. A request without a
production property will leave the production branch unchanged.
The branch_types property contains the branch types to be updated.
Only the branch types passed will be updated. All updates will be
rejected if it would leave the branching model in an invalid state.
For branch types this means that:
- The prefixes for all enabled branch types are valid. For example, it is not possible to use '*' inside a Git prefix.
- A prefix of an enabled branch type must not be a prefix of another enabled branch type. This is to ensure that a branch can be easily classified by its prefix unambiguously.
It is possible to store an invalid prefix if that branch type would be
left disabled. Only the passed properties will be updated. The
properties not passed will be left unchanged. Each branch type must
have a kind property to identify it.
The default_branch_deletion property is a string. The value of true
indicates to delete branches by default. The value of false indicates
that branches will not be deleted by default. A request without a
default_branch_deletion property will leave it unchanged. Other values
would be ignored.
Servers
- https://api.bitbucket.org/2.0
Path parameters
| Name | Type | Required | Description |
|---|---|---|---|
project_key |
String | Yes |
The project in question. This is the actual |
workspace |
String | Yes |
This can either be the workspace ID (slug) or the workspace UUID
surrounded by curly-braces, for example: |
How to start integrating
- Add HTTP Task to your workflow definition.
- Search for the API you want to integrate with and click on the name.
- This loads the API reference documentation and prepares the Http request settings.
- Click Test request to test run your request to the API and see the API's response.