Bitbucket Keyboard Shortcuts
Bitbucket's shortcut set closely tracks GitHub's for the core code-review actions — g then p to go to pull requests, for instance — since both platforms converged on similar single-letter-then-letter navigation patterns for browsing a Git host's web interface, likely reflecting how much cross-pollination there's been between teams that have used both. Where Bitbucket's shortcuts diverge is around its deep Jira integration: because linking a pull request or commit to a Jira issue is such a core part of the Atlassian workflow, several of Bitbucket's most useful shortcuts exist specifically to jump between a PR and its linked Jira issue without manually searching for it, a Jira-specific tie-in that neither GitHub nor GitLab replicates in quite the same integrated way. Pull request review shortcuts (approve, decline, add comment) matter heavily here too, since code review is Bitbucket's primary daily-use surface for most teams beyond the initial push and clone actions that happen at the Git CLI level rather than in the web interface at all. Organizations that have already standardized their whole software delivery lifecycle around Jira for planning, Confluence for documentation, and Bitbucket for source control get a genuinely different experience than a team using GitHub or GitLab alongside a separately purchased project tracker, since the linking between a commit, a pull request, and the original Jira ticket describing the work happens natively rather than through a third-party integration that has to be separately installed and maintained.
Navigation
| Action | Windows | Mac | Description |
|---|---|---|---|
| Go to Pull Requests | g then p | g then p | Navigates to the repository's pull request list, using the same two-key sequential pattern (press g, release, then press p) that GitHub also uses for its own navigation shortcuts. |
| Go to source code browser | g then c | g then c | Jumps to the repository's source file browser, letting you browse the codebase directly in the web interface without cloning locally first. |
| Focus search bar | / | / | Focuses the top-level search field to search across repositories, pull requests, and code by keyword. |
| Go to Branches | g then b | g then b | Navigates to the repository's branch list view, listing every active branch alongside its latest commit and any linked pull request status, reached through the identical two-key sequential pattern the rest of the Go-to shortcuts share. |
| Go to Pipelines | g then i | g then i | Jumps to the repository's CI/CD Pipelines section, showing recent build and deployment runs, using the same sequential letter-pair pattern as the other Go-to shortcuts in this list. |
Pull Requests
| Action | Windows | Mac | Description |
|---|---|---|---|
| Approve current pull request | Approve button (no dedicated key) | — | Marks the currently open pull request as approved by you, one of the core review actions in Bitbucket's code review workflow, primarily click-driven rather than keyboard-shortcut-driven. |
| Add inline comment on diff | Click line number + type | — | Adds a comment tied to a specific line in the pull request diff, standard convention shared with most Git hosting platforms' code review interfaces. |
| Merge pull request | Merge button (no dedicated key) | — | Merges the approved pull request into its target branch, with merge strategy options (merge commit, squash, fast-forward) configurable per repository. |
| Decline pull request | Decline button (no dedicated key) | — | Closes a pull request without merging it, typically used when a proposed change has been rejected or superseded by a different approach, leaving the branch itself unaffected but the request formally closed. |
| Request changes on a pull request | Request Changes button (no dedicated key) | — | Flags a pull request as needing revisions before it's mergeable, distinct from simply leaving comments, giving the review a formal blocking status until the author addresses the requested changes and a reviewer clears it. |
Jira Integration
| Action | Windows | Mac | Description |
|---|---|---|---|
| Link pull request to Jira issue | Type Jira issue key in PR title/description (auto-links) | — | Referencing a Jira issue key (like PROJ-123) anywhere in a commit message or pull request title/description automatically creates a linked reference, part of Bitbucket's deep integration with Jira that doesn't require a separate manual linking step. |
| Jump to linked Jira issue from PR | Click Jira issue badge on PR page | — | Navigates directly from a pull request's page to its linked Jira issue, letting reviewers see the original requirement or bug report context without leaving the linked workflow to search for it manually. |
| Trigger a Jira transition via smart commit | Include #done or similar keyword in commit message | — | Typing a smart-commit keyword like #done or #time alongside a Jira issue key in a commit message can automatically transition that issue's workflow status or log work time against it, a more powerful automated action than simple reference linking. |
Frequently Asked Questions
Why do Bitbucket's navigation shortcuts look so similar to GitHub's?
Both platforms independently converged on a similar 'press g, then a second letter' sequential navigation pattern for jumping between major sections of a repository's web interface, which has become something of a de facto convention across Git hosting platforms, making the transition between them relatively smooth for anyone already familiar with one.
Does linking a Jira issue in a commit message actually change the issue's status automatically?
Simply referencing an issue key links it as a reference, but Bitbucket's smart commits feature (typing specific keywords like #done or #time alongside the issue key) can trigger actual status transitions or log work time on the Jira issue directly from the commit message, which is a distinct, more powerful capability than plain reference linking.
Is Bitbucket's pull request review workflow meaningfully different from GitHub's or GitLab's?
The core actions (inline comments, approve, request changes, merge) are conceptually similar across all three platforms, though exact terminology and some workflow details (like Bitbucket's merge checks requiring a minimum number of approvals configurable per repository) differ, meaning teams switching between them usually adapt quickly but shouldn't assume every setting or shortcut carries over identically.
What happens to a smart commit's Jira transition if the commit is later reverted?
Reverting a commit doesn't automatically reverse the Jira transition that the original smart commit triggered — the issue's status change (or logged time) is a separate action already applied to Jira, so if a revert also needs to undo the issue's workflow state, that has to be handled manually in Jira rather than being automatically inferred from the Git-level revert.
Can a declined pull request be reopened later if the decision changes?
Yes — a declined pull request typically remains reopenable from its own page, restoring it to an active review state without needing to recreate it from scratch, as long as the source branch it was created from still exists and hasn't been deleted in the meantime. Teams that rely on this workflow generally treat reopening a declined request as routine rather than a special recovery procedure, since it costs nothing beyond a click if the source branch is still intact.
What's the difference between leaving a comment and formally requesting changes on a PR?
A plain comment is informational and doesn't affect whether the pull request can be merged, while Request Changes applies a blocking status that, depending on the repository's configured merge checks, can prevent merging until that specific reviewer either approves or the blocking request is otherwise cleared, making it the more formal of the two review actions.