GET /repositories/{workspace}/{repo_slug}/branching-model doesn't reflect project's inherited config

[Fernando Jesús Fernández Gallardo]

When a repository has "Enable inherited settings" turned on for its Branching Model (i.e. it inherits its Development branch from the Project-level Branching Model instead of defining its own), the GET /2.0/repositories/{workspace}/{repo_slug}/branching-model endpoint does not return the inherited/effective Development branch. It returns the repository's raw default state (main, use_mainbranch: true) instead, even though the Bitbucket web UI (Repository settings > Branching model) correctly shows and applies the Project's configured Development branch.

Per the API documentation, this endpoint returns the branching model "as applied to the repository", as a read-only view distinct from the settings endpoint used to change configuration. Since inheritance is a documented, first-class Project Settings feature, the "as applied" view should resolve through inheritance. Currently it does not.

STEPS TO REPRODUCE:

1. In a Bitbucket Project, configure an explicit Branching Model with the Development branch set to a specific branch other than the main branch (e.g. develop).
2. Create (or use) a repository inside that Project.
3. In that repository's own Branching Model settings, leave "Enable inherited settings" turned ON (the default). The UI correctly shows the Development branch as inherited from the Project.
4. Call GET https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/branching-model

EXPECTED RESULT:

"development": {"name": "develop", "use_mainbranch": false, ...}

ACTUAL RESULT:

"development": {"name": "main", "use_mainbranch": true, "branch": {"name": "main", "target": {"hash": "..."}, "type": "branch"}}

There is also no field in the response indicating the repository is in "inherited" mode, so an API consumer has no way to detect that the value returned doesn't reflect what's actually applied.

ADDITIONAL INFORMATION

This breaks third-party tooling that relies on this endpoint to determine a repository's actual development branch (for example, self-hosted Renovate's bbUseDevelopmentBranch option), causing silently incorrect behaviour with nothing surfaced as an error.

Documentation reference: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-branching-model/

[Viswanathan Ramachandran]

hi @Fernando Jesús Fernández Gallardo 

This is a known limitation of the repository-level /branching-model endpoint when the repository inherits its branching model from its project. That endpoint can return the repository’s local/raw branching-model state rather than the inherited value.

For the branch that Bitbucket is actually applying, have you tried using the dedicated effective-model endpoint instead:

GET /2.0/repositories/{workspace}/{repo_slug}/effective-branching-model

There is also an inheritance-state endpoint:

GET /2.0/repositories/{workspace}/{repo_slug}/override-settings

This can be used when an integration needs to know whether the repository is overriding the Project setting.