Documentation

Last updated in git: 2026-06-11

Groups

Groups let you manage access for multiple users at once. Instead of granting each user access to a repository individually, you grant the group and then add members to it. New members pick up all group grants immediately; removed members lose them.

Creating a group

/groups add <name>

Example:

/groups add backend-team

Expected output:

  created group 'backend-team'

Group names should be descriptive and lowercase. There are no strict naming rules enforced, but consistent conventions help when managing many groups.

Adding a user to a group

/groups assign <group> <login>

Example:

/groups assign backend-team alice
/groups assign backend-team bob

Expected output:

  added 'alice' to group 'backend-team'
  added 'bob' to group 'backend-team'

Both the user and the group are updated immediately. The user inherits all grants the group currently holds, and any future grants added to the group also apply to them.

A user can be a member of multiple groups. Their effective access is the union of all grants across their individual grants and every group they belong to.

Granting access to a group

/groups grant <group> <path> <role>

Example — give the whole team write access to two repositories:

/groups grant backend-team */git/api-service  writer
/groups grant backend-team */git/shared-lib   writer

The path and role work identically to /users grant. See Git access control and grants for the full path and wildcard reference.

Every member of backend-team — including any users added to the group in the future — can now push to both repositories.

Listing groups

/groups list

Expected output shape:

  backend-team         members: [alice, bob]
    grant: */git/api-service  writer
    grant: */git/shared-lib   writer

  readers              members: [carol]
    grant: */git/*  reader

Each group shows its members and all grants currently attached to it.

Revoking a group grant

/groups revoke <group> <path>

Example:

/groups revoke backend-team */git/shared-lib

This removes the group's grant on that path. Individual user grants on the same path are not affected. Members who had access through this group grant, and no other matching grant, immediately lose access.

Full example: setting up a team

Here is a complete walkthrough for a small team with different access levels.

1. Create the users

/users add alice  password-for-alice
/users add bob    password-for-bob
/users add carol  password-for-carol
/users add ci-bot password-for-ci

2. Create the groups

/groups add contributors
/groups add maintainers
/groups add automation

3. Assign members

/groups assign contributors alice
/groups assign contributors bob
/groups assign maintainers  carol
/groups assign automation   ci-bot

4. Grant group access

Contributors can push to the main project repository:

/groups grant contributors */git/my-project writer

Maintainers have full ownership (can delete refs, manage the repo):

/groups grant maintainers */git/my-project owner

The CI bot can read everything over SSH but write only to deployment config:

/groups grant automation ssh/git/* reader
/groups grant automation */git/deploy-config writer

5. Verify the setup

/groups list
  automation       members: [ci-bot]
    grant: ssh/git/*          reader
    grant: */git/deploy-config  writer

  contributors     members: [alice, bob]
    grant: */git/my-project   writer

  maintainers      members: [carol]
    grant: */git/my-project   owner

Alice and Bob can push. Carol can push and owns the repository. The CI bot can clone everything and push only to deploy-config.

6. Adding a new contributor later

When a new team member joins:

/users add dave password-for-dave
/groups assign contributors dave

Dave immediately gets write access to my-project without needing any individual grant. No other commands are needed.

How group grants interact with individual grants

A user's effective role for any given path is the highest role from any matching source:

  • their individual grants
  • grants from every group they belong to
  • the implicit self-ownership rule (if the path namespace matches their login)

These sources are additive. There is no way to use a group to deny access that an individual grant provides, or vice versa. If you need to remove access from a user who has it through a group, you must either remove them from the group or revoke the group grant entirely.

Read next

users groups access ops