[Other doc versions]
[Doc downloads]
Forks provide an alternative workflow to using branches, for where particular developers have restricted (read-only) access to a repository. See Workflow strategies in Stash for more information.
You can fork a repository into any other project in Stash for which you have admin access. You can also create personal forks and give other developers access to that using repository permissions.
You can create a fork for any repository that you can see in Stash (that is, for which you have 'read' permission).
Simply click Fork, near the top right of the screen, when viewing a repository. You can choose the location for the newly forked repository. Note that when a repository is forked into another project it will get that project's permissions, which may be less restrictive.
On this page:
Related pages:
When creating the fork you can enable fork syncing to have Stash automatically keep your fork up-to-date with changes in the upstream repository.
Pull requests for forks in Stash work just the way you'd expect. See Using pull requests in Stash.
When creating the pull request, you can choose the fork and the branch that contains the source to be pulled, as well as the destination fork and branch.
Once a pull request has been approved by reviewers, it can be merged as usual. See Using pull requests in Stash.
Once you fork a repository, your fork can be kept up-to-date with changes in the upstream repo either automatically by Stash or you can synchronize manually. You will still need to keep your remote working repository synced with your fork in Stash yourself. See Keeping forks synchronized for more details.
Forking of repositories is available by default. However, you can turn off forking, on a per-repository basis, if this helps you to control your development process. You can do this on the Repository details tab of the repository settings.
Note that disabling forking on the parent repo doesn't delete any existing forks, and doesn't prevent those existing forks from being forked. Pull requests will still work from the existing forks. Furthermore, commits in the parent are viewable via the fork if the SHA1 hash is known to the user.
Pre-receive hooks aren't copied with the fork and so are not run when code is merged in a pull-request. This means that custom hooks are unable to prevent certain changes from being merged by pull requests from forks. Instead, the hook would have to also implement a merge-check (see https://developer.atlassian.com/stash/docs/latest/how-tos/repository-hooks.html).