The purpose of a hosted DVCS is, in part, to allow geographically dispersed users to collaborate on code development. To do this effectively in Bitbucket, you need to understand public and private as it applies to repositories. You also need to understand what types of permissions you can grant to users in your repositories. This page covers the following topics:
Repository Creation for User Accounts and Teams
The account that creates a repository is known as its owner. An owner can be a user account or a team. Either can create unlimited Bitbucket public or private repositories. If you are a member of a team, you have the option of creating a repository under your person account or under the team account:
If a team member creates a repository for the team, the team is the repository owner and the team member is the repository creator.
Visibility is the notion that a repository is searchable through Bitbucket. Public repositories are visible to all Bitbucket users. When a private repository is created under a user account, the repository is visible only to its owner and users that owner gives access. If an account has created groups, group members automatically receive the access defined for that group. Teams typically have at least a Developers and an Administrators group.
Accounts without access cannot clone or view the contents of a private repository even if they know the repository's URL.
Permissions and Repositories
Repository owners and creators have administrative rights by default. Administrators can grant or deny other accounts access to a repository. An account plan only restricts access to private repositories. Administrators can allow 5, 10, 25, 50, or an unlimited number of users access to private repositories. For user accounts, the owner always counts as one user. For team accounts, the team account is not counted in the plan restriction.
Administrators configure the permissions associated with each user with access. Bitbucket supports the following permission levels:
|Level||This permissions allows a user to do the following:|
|read||View, clone, and fork the repository code. All public repositories grant all Bitbucket users read permissions automatically. Read access on a repository also allows users to create issues, comment on issues, and edit wiki pages.|
|write||Contribute to the repository by pushing changes directly from a repository on a local machine.|
|admin||Can do everything a repository owner can do. This means administrators can:|
Allowing or Restricting Forks
Public repositories allow public forks. To restrict forking you will have to make your repository private.
On a private repository's Admin page, in the Repository details section, you can choose one of the following:
- No forks: just what it says, no forks of the repository can be created by anyone including administrators (who, of course, can turn forking back on if they need to).
- Allow only private forks: will restrict any fork of the repository to remain private.
- Allow forks: will allow forks of the repository to be created and made public.
Even after you set No forks or Allow only private forks, any user with read, write, or admin permission to your private repository can still view your repository on Bitbucket and potentially copy its code. Forking and Cloning are different actions, restricting forks has no impact on the ability to clone a repository.
Groups for Providing Access
When you create a repository, Bitbucket checks to see if the owner's account has any groups with a default permissions (read, write, or admin) assigned. If you do, it adds that group to the new repository with the default permission. If you specify no default permissions, Bitbucket ignores that group. If you are concerned about inadvertently giving users access to your repositories, always specify no default group permissions. If you change your mind, you can always later go to the repository's Admin page and give the group access later.
Groups must be defined on your account or on teams that you administrate. If you are logged in as an individual user and create a repository for a team you administer, Bitbucket adds only the groups defined on the team account. It does not add groups defined on your individual account. As long as you have administrative rights on a repository, you can always add additional users and additional groups to a repository.
There are two levels you can change a group, at the account level or at the at the repository level. When you change the group at the repository level, you establish repository-level group settings. You can do this by changing the permission on the group to be different than what it is on the account or by removing the group all together from the repository. Once you establish repository-level permissions for a group, they remain in effect, no matter if you later change the permissions on the account-level.
Changing a group's permissions at the account level causes the system to change the permissions only for repositories that do not have repository-specific settings. If you add a new group at the account level, all existing repositories receive the new group automatically.
How Permissions work for Issue Trackers and Wikis
Repositories can include wikis and issue trackers. You can set the visibility (public or private) on a wiki or issue tracker independent of whether the corresponding repository is public or private.
For wikis, the following table describes the various settings you can set and what behaviors the settings enable:
|public||private||Only users who have access to the private repository can edit the wiki. Other Bitbucket users and any Internet browser can access the Wiki if you publish the URL.|
|private||private||Only Bitbucket users with access can view and edit the wiki.|
|public||public||Any Bitbucket user can search for the repository and then edit the Wiki. Other Bitbucket users and any Internet browser can also edit the wiki if you publish the URL.|
|private||public||Only Bitbucket users with access can view and edit the wiki.|
For issue trackers, the following table illustrates how you can set an issue tracker's visibility and what behaviors the settings enable.
|public||private||Only users who have access to the private repository can create an issue. Other Bitbucket users and any Internet browser can view the issue tracker if you publish the URL.|
|private||private||Only Bitbucket users with access to the repository can view, create, and update issues.|
|public||public||Any Bitbucket user can search for the repository and then view or create issues. Other Bitbucket users and any Internet browser can also view, create, and update issues if you publish the URL.|
|private||public||Only Bitbucket users with access to the repository can view, create, and update issues.|
Regardless of whether an issue tracker is public or private, only a user with admin rights can configure a repository's issue tracker.
Administer a repository
Managing the Users for your Bitbucket Account
Making your Bitbucket Repository Private or Public
Making your Bitbucket Wiki Private or Public
Making your Bitbucket Issues Private or Public