- Add a group README
- Change the owner of a group
- Change a group’s path
- Change the default branch protection of a group
- Use a custom name for the initial branch
- Share a group with another group
- Remove a shared group
- Transfer a group
- Disable email notifications
- Disable group mentions
- Export members as CSV
- User cap for groups
- Group file templates
- Group merge checks settings
- Group merge request approval settings
- Enable Code Suggestions
- Enable Experiment and Beta features
- Enable third-party AI features
- Group activity analytics
Manage groups
Use groups to manage one or more related projects at the same time.
Add a group README
As a group owner or member, you can use a README to provide more information about your team, and invite users to contribute to your projects. The README is displayed on the group overview page, and can be changed in the group settings. All group members can edit the README.
Prerequisite:
- To create the README from the group settings, you must have the Owner role for the group.
To add a group README:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- In the Group README section, select Add README. This action creates a new project
gitlab-profile
that contains theREADME.md
file. - On the prompt for creating a README, select Create and add README. You’re redirected to the Web IDE, where a README file is created.
- In the Web IDE, edit and commit the
README.md
file.
Change the owner of a group
You can change the owner of a group. Each group must always have at least one member with the Owner role.
- As an administrator:
- On the left sidebar, select Search or go to and find your group.
- Select Manage > Members.
- Give a different member the Owner role.
- Refresh the page. You can now remove the Owner role from the original owner.
- As the current group’s owner:
- On the left sidebar, select Search or go to and find your group.
- Select Manage > Members.
- Give a different member the Owner role.
- Have the new owner sign in and remove the Owner role from you.
Change a group’s path
Changing a group’s path (group URL) can have unintended side effects. Read how redirects behave before you proceed.
If you are changing the path so it can be claimed by another group or user, you must rename the group too. Both names and paths must be unique.
After you change the group path, the new group path is a new namespace and you must update the existing project URL in the following resources:
- Include statements.
- Docker image references in CI files.
- Variables that specify a project or namespace.
To retain ownership of the original namespace and protect the URL redirects, create a new group and transfer projects to it instead.
To change your group path (group URL):
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Advanced section.
- Under Change group URL, enter a new name.
- Select Change group URL.
Change the default branch protection of a group
- Introduced in GitLab 12.9.
- Settings moved and renamed in GitLab 14.9.
By default, every group inherits the branch protection set at the global level.
To change this setting for a specific group, see group level default branch protection.
To change this setting globally, see initial default branch protection.
Use a custom name for the initial branch
Introduced in GitLab 13.6.
When you create a new project in GitLab, a default branch is created with the first push. The group owner can customize the initial branch for the group’s projects to meet your group’s needs.
Share a group with another group
- Introduced in GitLab 12.7.
- Changed in GitLab 13.11 from a form to a modal window with a flag. Disabled by default.
- Modal window enabled on GitLab.com and self-managed in GitLab 14.8.
-
Generally available in GitLab 14.9.
Feature flag
invite_members_group_modal
removed.
Similar to how you share a project with a group,
you can share a group with another group. To invite a group, you must be a member of it.
To share a given group, for example, Frontend
with another group, for example,
Engineering
:
- Go to the
Frontend
group. - Select Manage > Members.
- Select Invite a group.
- In the Select a group to invite list, select
Engineering
. - Select a role as maximum access level.
- Select Invite.
After sharing the Frontend
group with the Engineering
group:
- The Groups tab lists the
Engineering
group. - The Groups tab lists a group regardless of whether it is a public or private group.
- All direct members of the
Engineering
group have access to theFrontend
group. The least access is granted between the access in theEngineering
group and the access in theFrontend
group.- If
Member1
has the Maintainer role inEngineering
andEngineering
is added toFrontend
with the Developer role,Member1
has the Developer role inFrontend
. - If
Member2
has the Guest role inEngineering
andEngineering
is added toFrontend
with the Developer role,Member2
has the Guest role inFrontend
.
- If
- Inherited members of the
Engineering
group do not gain access to theFrontend
group. - Direct members of the
Engineering
group who have the Group Invite badge next to their profile on the group’s usage quota page count towards the billable members of theFrontend
group.
Remove a shared group
To unshare a group:
- On the left sidebar, select Search or go to and find your group.
- Select Manage > Members.
- Select the Groups tab.
- To the right of the account you want to remove, select Remove group ().
For example, if the Engineering
group is shared with the Frontend
group, when
you unshare the Engineering
group:
- All direct members of the
Engineering
group no longer have access to theFrontend
group. - Members of the
Engineering
group no longer count towards the billable members of theFrontend
group.
Transfer a group
Transferring groups moves them from one place to another in the same GitLab instance. You can:
- Transfer a subgroup to a new parent group.
- Convert a top-level group into a subgroup by transferring it to the desired group.
- Convert a subgroup into a top-level group by transferring it out of its current group.
If you need to copy a group to a different GitLab instance, migrate the group by direct transfer.
When transferring groups, note:
- Changing a group’s parent can have unintended side effects. See what happens when a repository path changes.
- You must have the Owner role in the source and target group.
- You must update your local repositories to point to the new location.
- If the immediate parent group’s visibility is lower than the group’s current visibility, visibility levels for subgroups and projects change to match the new parent group’s visibility.
- Only explicit group membership is transferred, not inherited membership. If the group’s owners have only inherited membership, this leaves the group without an owner. In this case, the user transferring the group becomes the group’s owner.
- Transfers fail if npm packages exist in any of the projects in the group, or in any of its subgroups.
- Existing packages that use a group-level endpoint (Maven, NuGet, PyPI, Composer, and Debian) need to be updated per the package’s steps for setting up the group level endpoint.
- Existing package names need to be updated if the package uses an instance level endpoint (Maven, npm, Conan) and the group was moved to another root level namespace.
- Maven packages follow a naming convention that prevent installing or publishing the respective package from a group level endpoint after group transfer.
- Top-level groups that have a subscription on GitLab.com cannot be transferred. To make the transfer possible, the top-level group’s subscription must be removed first. Then the top-level group can be transferred as a subgroup to another top-level group.
To transfer a group:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Advanced section.
- In the Remove group section, select Transfer group.
- Select the group name in the drop down menu.
- Select Transfer group.
Disable email notifications
Introduced in GitLab 12.2.
You can disable all email notifications related to the group, which includes its subgroups and projects.
To disable email notifications:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Permissions and group features section.
- Select Email notifications are disabled.
- Select Save changes.
Disable group mentions
Introduced in GitLab 12.6.
You can prevent users from being added to a conversation and getting notified when anyone mentions a group in which those users are members.
Groups with disabled mentions are visualized accordingly in the autocompletion dropdown list.
This is particularly helpful for groups with a large number of users.
To disable group mentions:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Permissions and group features section.
- Select Group mentions are disabled.
- Select Save changes.
Export members as CSV
- Introduced in GitLab 14.2.
- Feature flag removed in GitLab 14.5.
You can export a list of members in a group or subgroup as a CSV.
- On the left sidebar, select Search or go to and find your group or subgroup.
- On the left sidebar, Manage > Members.
- Select Export as CSV.
- After the CSV file has been generated, it is emailed as an attachment to the user that requested it.
The output lists direct members and members inherited from the ancestor groups.
For members with Minimal Access
in the selected group, their Max Role
and Source
are derived from their membership in subgroups.
Issue 390358 tracks the discussion about the group members CSV export list not matching the UI members list.
User cap for groups
-
Introduced in GitLab 14.7 with a flag named
saas_user_caps
. Disabled by default. - Enabled on GitLab.com in GitLab 16.3.
For more information about user caps for GitLab self-managed, see User cap.
When the number of billable members reaches the user cap, new users can’t be added to the group without being approved by the group owner.
Groups with the user cap feature enabled have group sharing disabled for the group and its subgroups.
Specify a user cap for a group
Prerequisite:
- You must be assigned the Owner role for the group.
To specify a user cap:
- On the left sidebar, select Search or go to and find your group. You can set a cap on the top-level group only.
- Select Settings > General.
- Expand Permissions and group features.
- In the User cap box, enter the desired number of users.
- Select Save changes.
If you already have more users in the group than the user cap value, users are not removed. However, you can’t add more without approval.
Increasing the user cap does not approve pending members.
Remove the user cap for a group
You can remove the user cap, so there is no limit on the number of members you can add to a group.
Prerequisite:
- You must be assigned the Owner role for the group.
To remove the user cap:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand Permissions and group features.
- In the User cap box, delete the value.
- Select Save changes.
Decreasing the user cap does not approve pending members.
Approve pending members for a group
When the number of billable users reaches the user cap, any new member is put in a pending state and must be approved.
Pending members do not count as billable. Members count as billable only after they have been approved and are no longer in a pending state.
Prerequisite:
- You must be assigned the Owner role) for the group.
To approve members that are pending because they’ve exceeded the user cap:
- On the left sidebar, select Search or go to and find your group.
- On the left sidebar, select Settings > Usage Quotas.
- On the Seats tab, under the alert, select View pending approvals.
- For each member you want to approve, select Approve.
Known issues
The user cap cannot be enabled if a group, subgroup, or project is shared externally. If a group, subgroup, or project is shared externally, it is shared outside of the namespace hierarchy, regardless of its level in the hierarchy.
To ensure that the user cap applies when groups, subgroups, or projects are shared externally, restrict group sharing only within the top-level namespace. This ensure that groups in the same top-leve namespace can be invited, and prevents the addition of new users (seats) when the group is shared.
User cap doesn’t consider whether users are billable or not (e.g., Free Guest Users in Ultimate). In other words, if you set a cap of 500, user caps block new sign-ups after 500 users, regardless of whether those are all consuming paid seats or not.
Group file templates
Use group file templates to share a set of templates for common file types with every project in a group. It is analogous to the instance template repository. The selected project should follow the same naming conventions as are documented on that page.
You can only choose projects in the group as the template source. This includes projects shared with the group, but it excludes projects in subgroups or parent groups of the group being configured.
You can configure this feature for both subgroups and immediate parent groups. A project in a subgroup has access to the templates for that subgroup and any immediate parent groups.
To learn how to create templates for issues and merge requests, see description templates.
Define project templates at a group level by setting a group as the template source. For more information, see group-level project templates.
Enable group file template
To enable group file templates:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Templates section.
- Choose a project to act as the template repository.
- Select Save changes.
Group merge checks settings
Introduced in GitLab 15.9 with a flag name support_group_level_merge_checks_setting
. Disabled by default.
support_group_level_merge_checks_setting
. On GitLab.com, this feature is not
available.Group owners can set up merge request checks on a top-level group, which apply to all subgroups and projects.
If the settings are inherited by a subgroup or project, they cannot be changed in the subgroup or project that inherited them.
Require a successful pipeline for merge
You can configure all child projects in your group to require a complete and successful pipeline before merge.
See also the project-level setting.
Prerequisites:
- You must be the owner of the group.
To enable this setting:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand Merge requests.
- Under Merge checks, select Pipelines must succeed. This setting also prevents merge requests from being merged if there is no pipeline.
- Select Save changes.
Allow merge after skipped pipelines
You can configure skipped pipelines from preventing merge requests from being merged.
See also the project-level setting.
Prerequisite:
- You must be the owner of the group.
To change this behavior:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand Merge requests.
- Under Merge checks:
- Select Pipelines must succeed.
- Select Skipped pipelines are considered successful.
- Select Save changes.
Prevent merge unless all threads are resolved
You can prevent merge requests from being merged until all threads are resolved. When this setting is enabled, for all child projects in your group, the Unresolved threads count in a merge request is shown in orange when at least one thread remains unresolved.
Prerequisite:
- You must be the owner of the group.
To enable this setting:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand Merge requests.
- Under Merge checks, select All threads must be resolved.
- Select Save changes.
Group merge request approval settings
-
Introduced in GitLab 13.9. Deployed behind the
group_merge_request_approval_settings_feature_flag
flag, disabled by default. - Enabled by default in GitLab 14.5.
-
Feature flag
group_merge_request_approval_settings_feature_flag
removed in GitLab 14.9.
Group approval settings manage project merge request approval settings for all projects in a top-level group. These settings cascade to all projects that belong to the group.
To view the merge request approval settings for a group:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand the Merge request approvals section.
- Select the settings you want.
- Select Save changes.
Approval settings should not be confused with approval rules. Support for the ability to set merge request approval rules for groups is tracked in epic 4367.
Enable Code Suggestions
- Introduced in GitLab 15.11.
- Moved from GitLab Ultimate to GitLab Premium in 16.0.
- Moved from GitLab Premium to GitLab Free in 16.0.
You can give all users in a group and its subgroups access to Code Suggestions.
- This setting cascades to all projects in the group.
- Each user can enable Code Suggestions.
Code Suggestions are enabled by default at the group level.
To update this setting:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand Permissions and group features.
- Under Code Suggestions, select the Projects in this group can use Code Suggestions checkbox.
- Select Save changes.
Enable Experiment and Beta features
Introduced in GitLab 16.0.
You can give all users in a top-level group access to Experiment and Beta features. This setting cascades to all projects that belong to the group.
To enable Experiment features for a top-level group:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand Permissions and group features.
- Under Experiment and Beta features, select the Use Experiment and Beta features checkbox.
- Select Save changes.
Enable third-party AI features
Introduced in GitLab 16.0.
All users in the group have third-party AI features enabled by default. This setting cascades to all projects that belong to the group.
To disable third-party AI features for a group:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > General.
- Expand Permissions and group features.
- Under Third-party AI services, uncheck the Use third-party AI services checkbox.
- Select Save changes.
When Code Suggestions are enabled and disabled, an audit event is created.
Group activity analytics
Introduced in GitLab 12.10 as a Beta feature.
For a group, you can view how many merge requests, issues, and members were created in the last 90 days.
These Group Activity Analytics can be enabled with the group_activity_analytics
feature flag.
Changes to group wikis do not appear in group activity analytics.
View group activity
You can view the most recent actions taken in a group, either in your browser or in an RSS feed:
- On the left sidebar, select Search or go to and find your group.
- On the left sidebar, select Manage > Activity.
To view the activity feed in Atom format, select the RSS () icon.