Baixar bb 5.0.0 per a Windows

v5.0.0
bb v5.0.0 works with every Bitbucket Data Center release Atlassian supports, completes what you type from your own Bitbucket, and makes its MCP server something you work with: it asks you before it merges, takes the pull request or file you hand it, and shows what it found as a view in your client.
It is a major release. Seven changes can break a script, a pipeline or an MCP configuration. They are under "Before you upgrade", each with what to change, and are the part to read first if bb runs in CI, in scripts or under an AI agent. What is deprecated keeps working until v6.0.0 and is listed at the end.
New at the command line
- Every Bitbucket Data Center release Atlassian supports (ADR-088, #307):
bb was built against the newest Bitbucket release and tested against that one alone. It now works with every release Atlassian supports, each tested against a real instance of it, and a release keeps working after Atlassian's support for it ends.
An older release behaves like the newest except where it lacks something a later one added. There bb answers as the newest release would where it can, and otherwise refuses before it sends anything, naming the release that can do it:
$ bb branch restriction create --repo PROJ/app --type no-creates --matcher-id refs/heads/main
unsupported: a no-creates branch restriction is not supported by this Bitbucket version (9.2.1); it needs 9.4.0 or later
Before, Bitbucket accepted such a request and dropped the part it did not know, so a required build meant to spare pull requests blocked every one of them. unsupported, exit 14, is a new error kind: a script that lists the kinds or exit codes it handles gains one. Bitbucket Versions lists the four places where a release differs.
- Tab completion that knows your Bitbucket (ADR-089, #407, #397):
Press tab after bb pr merge and bb lists the open pull requests of the repository you are in, by number and title. After bb branch delete it lists the branches, each with its latest commit message. Projects, repositories, tags, reviewers, file paths and the values a flag accepts complete the same way, read from your Bitbucket with your own credentials, in bash, zsh, fish and PowerShell.
Homebrew and the .deb and .rpm packages set it up for bash, zsh and fish when they install bb, and Scoop sets it up for PowerShell, along with the agent skill. Anywhere else one command does it, and bb doctor says whether it is in place:
bb completion install
- bb pr create needs no flags in a checkout, and bb pr merge takes a strategy (ADR-102, #705):
Standing on a pushed branch, bb pr create is enough. The source is the branch that is checked out, the target is the repository's default branch, and the title is the commit's subject when the branch holds exactly one commit. At a terminal each is offered for you to accept or change. With nobody to ask they are used as they are and named on stderr, and a branch that holds several commits still needs --title. It prints the pull request's link, which every reported pull request now carries as url.
git push -u origin feature/refunds
bb pr create
bb pr merge 42 --strategy squash
--strategy takes any strategy the repository enables, and its default applies without it. --dry-run says so first when the repository has not enabled the one asked for.
- bb search prs takes a period, so it can answer "what did I work on" (#697):
What it lists has not changed. Without --repo that is every pull request you are involved in across every repository, whether you wrote it, are a reviewer on it or took part in it, and --role picks one of the three. What is new is the period: --since and --until bound the listing on the created, updated or closed date that --date-field names, and --group-by week or repo arranges the text output. With --since the listing holds the whole period rather than the first 25.
bb search prs --role author --state all --since 2026-07-20 --until 2026-09-27 --group-by week
- --state takes merged and declined, in bb pr list too, and all and closed no longer fail across repositories.
- A pull request reports closedDate once it is merged or declined, and the issue keys its title and source branch mention:
{
"data": {
"pullRequests": [
{
"id": 6,
"title": "PAY-12: retry a declined refund",
"state": "MERGED",
"open": false,
"closed": true,
"repository": { "projectKey": "PAY", "slug": "ledger" },
"sourceRepository": { "projectKey": "PAY", "slug": "ledger" },
"version": 2,
"author": "Administrator",
"authorUsername": "admin",
"sourceBranch": "feature/refunds",
"targetBranch": "master",
"sourceCommit": "6b9cb2216ad56a58f976325627a2d87ad41d6a2a",
"createdDate": 1790758330929,
"updatedDate": 1790758331777,
"closedDate": 1790758331777,
"url": "https://bitbucket.example.com/projects/PAY/repos/ledger/pull-requests/6",
"issueKeys": ["PAY-12"],
"commentCount": 0,
"openTaskCount": 0,
"resolvedTaskCount": 0
}
]
},
"meta": { "command": "search prs", "limitReached": true, "bbVersion": "..." }
}
- bb branch list --details prints the details. It lists what Bitbucket's branch page shows beside each branch: how far it is ahead of and behind the default branch, its last commit, its builds and its pull requests. --base measures against another branch, tag or commit, and asks for the details by itself. Both flags used to be accepted and change nothing.
$ bb branch list --repo PAY/ledger --details
feature/refunds refs/heads/feature/refunds 6b9cb2216ad56a58f976325627a2d87ad41d6a2a default=false ahead=2 behind=1 2026-09-28 alice pr=#42 OPEN builds=1 successful, 1 failed
master refs/heads/master 0d4e1c7a9b3f52e86a1d7c40b9e2f35a6c8d1e07 default=true 2026-09-27 bob
Under --json each branch gains ahead, behind, lastCommit, builds and pullRequests, each left out when Bitbucket has nothing to report: the base has no counts, and a branch nobody built has no builds. Bitbucket names the pull request when a branch has exactly one, as only, and gives the counts alone when it has more:
{
"data": {
"repository": { "projectKey": "PAY", "slug": "ledger" },
"branches": [
{
"id": "refs/heads/feature/refunds",
"displayId": "feature/refunds",
"latestCommit": "6b9cb2216ad56a58f976325627a2d87ad41d6a2a",
"default": false,
"ahead": 2,
"behind": 1,
"lastCommit": {
"id": "6b9cb2216ad56a58f976325627a2d87ad41d6a2a",
"displayId": "6b9cb2216ad",
"message": "PAY-12: retry a declined refund",
"author": { "name": "alice", "emailAddress": "alice@example.com" },
"authorTimestamp": 1790586000000,
"committer": { "name": "alice", "emailAddress": "alice@example.com" },
"committerTimestamp": 1790586000000,
"parents": ["0d4e1c7a9b3f52e86a1d7c40b9e2f35a6c8d1e07"]
},
"builds": { "successful": 1, "failed": 1, "inProgress": 0, "unknown": 0, "cancelled": 0 },
"pullRequests": {
"open": 1,
"merged": 0,
"declined": 0,
"only": { "id": 42, "title": "PAY-12: retry a declined refund", "state": "OPEN" }
}
}
]
},
"meta": { "command": "branch list", "limitReached": false, "bbVersion": "..." }
}
- --yaml (ADR-095, #606):
Every command that takes --json takes --yaml, and prints the same document as YAML, for a pipeline that keeps its data in YAML or for reading a long answer at a terminal. --dry-run and --describe follow it too. bb --yaml branch list --repo PAY/ledger --filter develop:
data:
repository:
projectKey: PAY
slug: ledger
branches:
- id: refs/heads/develop
displayId: develop
latestCommit: f62bfb84cba2a12ef7f2437dfc8c084ac61c489d
default: false
meta:
command: branch list
limitReached: false
bbVersion: "..."
- Examples in every --help, and a reference page per command (#604, #701):
The help of every command ends with examples to copy, showing the values a flag's description leaves you to guess. The command reference on the site has a page per command in place of one long page, with each flag under the command it comes from.
New in the MCP server
The server also asks you before a tool merges, or decides what merges. That changes an existing setup, so it is under "Before you upgrade".
- Put a pull request, a diff or a file in front of the AI yourself (ADR-099, #685):
Until now the AI only saw what it went and fetched through bb's tools, so you had to hope it found the right pull request or file. Now you can hand it Bitbucket content yourself, the way you attach a file to a message: the pull request you are reviewing, its diff or its open comments, a file on any branch, tag or commit, or a single commit. Your MCP client helps you find it, suggesting projects, repositories, pull requests, paths and branches as you type, and it lists your own open pull requests and the ones waiting on your review, so the one you want is usually a click away.
In VS Code, for example, choose Add Context > MCP Resources, pick the diff of pull request 42 in PAYMENTS/ledger, and ask what could break. Or type /bitbucket.review_pull_request to attach a pull request with its diff and open comments and ask for a review in one step. It works the same in any MCP client, including chat apps without a terminal, and everything still goes through bb, with its token, its --project and --repo scope and its audit trail. Your client never talks to Bitbucket itself.
- See a pull request, a list or a diff as a view in your MCP client (ADR-101, #686):