- Use cases
- Issues and merge requests within a group
- Create a new group
- Add users to a group
- Request access to a group
- Add projects to a group
- Transfer an existing project into a group
- Sharing a project with a group
- Manage group memberships via LDAP
- Group settings
With GitLab Groups you can assemble related projects together and grant members access to several projects at once.
Groups can also be nested in subgroups.
Find your groups by expanding the left menu and clicking Groups:
The Groups page displays all groups you are a member of, how many projects it holds, how many members it has, the group visibility, and, if you have enough permissions, a link to the group settings. By clicking the last button you can leave that group.
You can create groups for numerous reasons. To name a few:
- Organize related projects under the same namespace, add members to that group and grant access to all their projects at once
- Create a group, include members of your team, and make it easier to
@mentionall the team at once in issues and merge requests
- Create a group for your company members, and create subgroups
for each individual team. Let's say you create a group called
company-team, and among others, you created subgroups in this group for each individual team
- When you start a new implementation from an issue, you add a comment:
@company-team, let's do it!
@company-team/backend-teamyou're good to go!"
- When your backend team needs help from frontend, they add a comment:
@company-team/frontend-teamcould you help us here please?"
- When the frontend team completes their implementation, they comment:
@company-team/backend-team, it's done! Let's ship it
- When you start a new implementation from an issue, you add a comment: "
- Create a group for your company members, and create subgroups for each individual team. Let's say you create a group called
In GitLab, a namespace is a unique name to be used as a user name, a group name, or a subgroup name.
For example, consider a user called John:
- John creates his account on GitLab.com with the username
john; his profile will be accessed under
- John creates a group for his team with the groupname
john-team; his group and its projects will be accessed under
- John creates a subgroup of
john-teamwith the subgroup name
marketing; his subgroup and its projects will be accessed under
By doing so:
- Any team member mentions John with
- John mentions everyone from his team with
- John mentions only his marketing team with
- For a list of words that are not allowed to be used as group names see the reserved names.
You can create a group in GitLab from:
The Groups page: expand the left menu, click Groups, and click the green button New group:
Elsewhere: expand the
plussign button on the top navbar and choose New group:
Add the following information:
- Set the Group path which will be the namespace under which your projects will be hosted (path can contain only letters, digits, underscores, dashes and dots; it cannot start with dashes or end in dot).
- The Group name will populate with the path. Optionally, you can change it. This is the name that will display in the group views.
- Optionally, you can add a description so that others can briefly understand what this group is about.
- Optionally, choose an avatar for your project.
- Choose the visibility level.
Add members to a group by navigating to the group's dashboard, and clicking Members:
Select the permission level and add the new member. You can also set the expiring date for that user, from which they will no longer have access to your group.
One of the benefits of putting multiple projects in one group is that you can give a user to access to all projects in the group with one action.
Consider we have a group with two projects:
- On the Group Members page we can now add a new user to the group.
- Now because this user is a Developer member of the group, he automatically gets Developer access to all projects within that group.
If necessary, you can increase the access level of an individual user for a specific project, by adding them again as a new member to the project with the new permission levels.
As a group owner you can enable or disable non members to request access to your group. Go to the group settings and click on Allow users to request access.
As a user, you can request to be a member of a group. Go to the group you'd like to be a member of, and click the Request Access button on the right side of your screen.
Group owners and masters will be notified of your request and will be able to approve or decline it on the members page.
If you change your mind before your request is approved, just click the Withdraw Access Request button.
There are two different ways to add a new project to a group:
Select a group and then click on the New project button.
You can then continue on creating a project.
While you are creating a project, select a group namespace you've already created from the dropdown menu.
You can transfer an existing project into a group as long as you have at least Master permissions to that group and if you are an Owner of the project.
Find this option under your project's settings.
GitLab administrators can use the admin interface to move any project to any namespace if needed.
You can share your projects with a group and give your group members access to the project all at once.
Alternatively, you can lock the sharing with group feature.
In GitLab Enterprise Edition it is possible to manage GitLab group memberships using LDAP groups. See the GitLab Enterprise Edition documentation for more information.
Introduced in GitLab Enterprise Edition Ultimate 10.2.
Epics let you manage your portfolio of projects more efficiently and with less effort by tracking groups of issues that share a theme, across projects and milestones.
Once you have created a group, you can manage its settings by navigating to the group's dashboard, and clicking Settings.
Besides giving you the option to edit any settings you've previously set when creating the group, you can also access further configurations for your group.
Note: If you want to retain ownership over the original namespace and protect the URL redirects, then instead of changing a group's path or renaming a username, you can create a new group and transfer projects to it.
Changing a group's path can have unintended side effects.
- Existing web URLs for the group and anything under it (i.e. projects) will redirect to the new URLs
- Existing Git remote URLs for projects under the group will no longer work, but Git responses will show an error with the new remote URL
- The original namespace can be claimed again by any group or user, which will destroy web redirects and Git remote warnings
- If you are vacating the path so it can be claimed by another group or user, you may need to rename the group name as well since both names and paths must be unique
It is currently not possible to rename a namespace if it contains a project with container registry tags, because the project cannot be moved.
Add a security layer to your group by enforcing two-factor authentication (2FA) to all group members.
Prevent projects in a group from sharing a project with another group. This allows for tighter control over project access.
For example, consider you have two distinct teams (Group A and Group B) working together in a project. To inherit the group membership, you share the project between the two groups A and B. Share with group lock prevents any project within the group from being shared with another group. By doing so, you guarantee only the right group members have access to that projects.
To enable this feature, navigate to the group settings page. Select Share with group lock and Save the group.
Available in GitLab Enterprise Edition Starter, with Member Lock it is possible to lock membership in project to the level of members in group.
Member Lock lets a group owner to lock down any new project membership to all the projects within the group, allowing tighter control over project membership.
For instance, if you want to lock the group for an Audit Event, you enable Member Lock to guarantee that any membership is added or changed during the audition.
To enable this feature, navigate to group settings page, select Member lock and Save group.
This will disable the option for all users who previously had permissions to operate project memberships so no new users can be added. Furthermore, any request to add new user to project through API will not be possible.
- Projects: view all projects within that group, add members to each project, access each project's settings, and remove any project from the same screen.
- Webhooks: configure webhooks and push rules to your group (Push Rules is available in GitLab Enteprise Edition Starter.)
- Audit Events: view Audit Events for the group (GitLab admins only, available in GitLab Enterprise Edition Starter)
- Pipelines quota: keep track of the pipeline quota for the group