Add users to the team's groups, giving them access permissions for repositories.

Now that you understand the relationship between users, groups, and repositories, let's see at what they look like in Bitbucket.

Every team has two user groups by default, an Administrators user group and a Developers user group. Here's an example of what one of your user groups will look like. You can see the group's access permissions and the users part of that group. Learn more about user groups.

Let's take a look at the access page of a repository. The team's groups were added to the repository with their default permissions, but you can change a group's access at any time. Learn more about repository access settings.

If a team member has permission to create team repositories, that user becomes an admin for each repository they create.

How your team could work

Now that you know how teams work, let's look at some examples of how team and repository setup could work for different types of teams. Keep in mind that they are only examples, and you can organize your team based on what makes sense for your organization.

Small team

Small teams (2-10 users) generally require the simplest setup. Because every team already has the Administrators and Developers user groups, you can update the permissions you want your team to have without creating any new groups. Then, all you need to do is add users to both groups to give your small team both simple access controls and flexibility.

User groups for a small team:

Group name

Default repo access

Team permissions

Administrators

Admin

Administer team, Create repositories

Developers

Write

Create repositories

Repository scenario for user group example:

Repo 1: John (part of Administrators) creates Repo 1.

Developers group has default Write access.

Repo 2: Shelly (part of Developers) creates Repo 2.

She has automatic Admin access on the repo she created.

Developers group has default Write access.

Large company with separate teams

When you have multiple software teams in a large company, you create one team for all your users so that you have only one billing account. With that one team, you can create separate user groups for all the different groups at your company. These groups could be based on roles, products, or features. This scenario bases them on feature teams and could work for a team way over 100 users.

Example user groups for a large company with separate teams:

Group name

Default repo access

Team permissions

Administrators

Admin

Administer team, Create repositories

Developers 1

Read

Create repositories

Developers 2

Read

Create repositories

Developers 3

Read

Create repositories

Developers 4, Developers 5, etc.

Repository scenario for user group example:

Repo 1: Paula (part of Administrators) creates Repo 1.

She gives Developers 1 Write access.

Developers 1 and 2 have default Read access.

Repo 2: Paula (part of Administrators) creates Repo 2.

She gives Developers 2 Write access.

Developers 1 and 2 have default Read access.

Repo 3: Dave (part of Developers 3) creates Repo 3.

He has automatic Admin access on the repo he created.

He gives Developers 3 Write access.

Developers 1 and 2 have default Read access.

Medium-size team with temporary contractors

When your team is made up of full-time developers and/or temporary contractors, you may need to give different permissions to each group. For example, you can specify default access for no one in the contractors group. However, as they need access to repositories, you can go into that repository and turn onwriteor readaccess for the group that needs it. This scenario could also include more developer or external groups.

Example user groups for a medium-size team with temporary contractors:

Group name

Default repo access

Team Permissions

Administrators

Admin

Administer team, Create repositories

Developers

Write

Create repositories

External group

None

None

Repository scenario for user group example:

Repo 1: Will (part of Administrators) creates Repo 1.

Developers group has default Write access.

Repo 2: Julie (part of Developers) creates Repo 2.

She has automatic Admin access on the repo he created.

She gives External group Read access.

Developers group has default Write access.

Repo 3: Steve (part of Administrators) creates Repo 3.

He gives External group Write access.

Developers group has default Write access.

Medium-size team with non-developer users

If you don't need to place different permissions on different groups of developers, another way to set up your team's user groups is by roles. In this case, you'll most likely have less overlap between groups. You may also have very different access levels between groups if you want one group, for example developers, to have more access than other groups. This scenario could also include more users and groups.