Fork a repository
Starting July 1, 2026, Atlassian is making a few changes that impact cross workspace forked repositories:
The ability to create new cross workspace forks will be deprecated. We previously communicated this would be removed February 27, 2026, but are now extending this to July 1, 2026. We want to give enough time to manage outstanding forks and update your software development workflows as needed.
Atlassian will NOT be moving any forked repositories into the parent workspace on your behalf. Forked repository relationships with other workspaces will be automatically broken on this date. Once forked repository relationships are broken, all pull request functionality will remain as normal/expected.
Please note: Cross-workspace PRs that have already been created will be able to be viewed and merged. You will not be able to create a cross-workspace PR from the fork to the parent if the relationship is broken, but will be able to continue creating PRs from child to parent if both repositories exist in the same workspace.
If you would like to break the forked repository relationship to the parent repository, you can do so today by contacting support.
If you are a repository admin and would like to do this yourself, we are building a self-serve feature to support this. This page will be updated once available.
In Git, you create branches by starting with either the head/trunk or an existing branch. When you do this, your changes become part of the main project repository. If you want to work on a completely separate copy of the project, you may want to consider creating a 'fork'.
Forking is a way for you to clone a repository at a specific point, and to modify it from there. To fork is just another way of saying clone. Bitbucket Cloud manages the relationship between the original repository and the fork for you. Forking is particularly useful if you want to do some major development work that you may or may not later merge back into the repository. Here is the basic workflow:
Create a fork on Bitbucket.
Clone the forked repository your local system.
Modify the local repository.
Commit your changes.
Push changes back to the remote fork on Bitbucket.
Create a pull request from the forked repository (source) back to the original (destination).
The final step in the workflow is for the owner of the original repository to merge your changes.
Fork a repository
Go to a repository, select the More options () button in the upper-right corner.
Select Fork this repository from the dropdown menu.
In the Fork dialog, define the options for your fork.
Workspace: This defaults to the logged-in account. If you have the rights to create repositories in more than one workspace, this is a drop-down. Please keep in mind, starting July 1, 2026, the ability to create new repository forks will be limited to the parent workspace.
Project: Name of your project. If you have more than one project, you can select a project from the dropdown menu.
Name: This will be the name of the forked repository. You can update this field.
Access level: By default, the system creates your fork with the same access level as the original. So, if the original is public your fork is too. You can change this, making your fork private. An administrator of the original repository can prevent public forks; In this case, then you cannot change the access.
Permissions: By default, your fork inherits the user/group permissions. For example, if 4 accounts have access to the original your fork will give them the same access. Forking a public repo under your account can cause you to go over the limit on your Bitbucket plan. You can avoid the impact to your plan by making your fork private or by not inheriting the users from the original repo.
Advanced settings
Description: Add a description to your fork.
Forking: Choose your forking preference:
Allow forks—Users can fork the repository and those forks can be public. Starting July 1, 2026, the ability to create new repository forks will be limited to the parent workspace.
Allow only private forks—Users can fork the repository and those forks will be private.
No forks—Users can't fork the repository.
Workspace forking policy enabled
If the workspace administrator has set the forking policy to prevent forking outside of the workspace then Allow forks will not be an available option. The forking policy set at the workspace level has precedence over the repository settings.
Note: If Allow forks is enabled on repositories when a workspace admin enables the new forking policy, you will be prompted to update this forking option and the Allow forks option will no longer be available.
3. Select the Fork repository button.
The system creates the fork and opens the repository's Source page.
Was this helpful?