30 KiB
type | stage | group | info |
---|---|---|---|
reference, howto | Manage | Access | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments |
Groups (FREE)
In GitLab, you can put related projects together in a group.
For example, you might create a group for your company members and a subgroup for each individual team.
You can name the group company-team
, and the subgroups backend-team
, frontend-team
, and production-team
.
Then you can:
- Grant members access to multiple projects at once.
- Add to-do items for all of the group members at once.
- View the issues and merge requests for all projects in the group, together in a single list view.
- Bulk edit issues, epics, and merge requests.
You can also create subgroups.
View groups
To view groups:
- In the top menu, select Groups > Your Groups. All groups you are a member of are displayed.
- To view a list of public groups, select Explore public groups.
You can also view groups by namespace.
Namespaces
In GitLab, a namespace is a unique name and URL for a user, a group, or subgroup.
http://gitlab.example.com/username
http://gitlab.example.com/groupname
http://gitlab.example.com/groupname/subgroup_name
For example, consider a user named Alex:
- Alex creates an account with the username
alex
:https://gitlab.example.com/alex
- Alex creates a group for their team with the group name
alex-team
. The group and its projects are available at:https://gitlab.example.com/alex-team
- Alex creates a subgroup of
alex-team
with the subgroup namemarketing
. The subgroup and its projects are available at:https://gitlab.example.com/alex-team/marketing
Create a group
To create a group:
-
From the top menu, either:
- Select Groups > Your Groups, and on the right, select the New group button.
- To the left of the search box, select the plus sign and then New group.
-
For the Group name, use only:
- Alphanumeric characters
- Emojis
- Underscores
- Dashes, dots, spaces, and parentheses (however, it cannot start with any of these characters)
For a list of words that cannot be used as group names, see reserved names.
-
For the Group URL, which is used for the namespace, use only:
- Alphanumeric characters
- Underscores
- Dashes and dots (it cannot start with dashes or end in a dot)
-
Choose the visibility level.
-
Invite GitLab members or other users to join the group.
For details about groups, watch GitLab Namespaces (users, groups and subgroups).
Add users to a group
You can give a user access to all projects in a group.
- From the top menu, select Groups > Your Groups.
- Find your group and select it.
- From the left sidebar, select Members.
- Fill in the fields.
- The role applies to all projects in the group. Learn more about permissions.
- On the Access expiration date, the user can no longer access projects in the group.
Request access to a group
As a user, you can request to be a member of a group, if an administrator allows it.
- From the top menu, select Groups > Your Groups.
- Find the group and select it.
- Under the group name, select Request Access.
As many as ten of the most-recently-active group owners receive an email with your request. Any group owner can approve or decline the request.
If you change your mind before your request is approved, select Withdraw Access Request.
Prevent users from requesting access to a group
As a group owner, you can prevent non-members from requesting access to your group.
- From the top menu, select Groups > Your Groups.
- Find the group and select it.
- From the left menu, select Settings > General.
- Expand the Permissions, LFS, 2FA section.
- Clear the Allow users to request access checkbox.
- Select Save changes.
Change the owner of a group
You can change the owner of a group. Each group must always have at least one member with Owner permission.
- As an administrator:
- Go to the group and from the left menu, select Members.
- Give a different member Owner permissions.
- Refresh the page. You can now remove Owner permissions from the original owner.
- As the current group's owner:
- Go to the group and from the left menu, select Members.
- Give a different member Owner permissions.
- Have the new owner sign in and remove Owner permissions from you.
Remove a member from the group
Prerequisites:
- You must have Owner permissions.
- The member must have direct membership in the group. If membership is inherited from a parent group, then the member can be removed from the parent group only.
To remove a member from a group:
- Go to the group.
- From the left menu, select Members.
- Next to the member you want to remove, select Delete.
- Optional. On the Remove member confirmation box, select the Also unassign this user from related issues and merge requests checkbox.
- Select Remove member.
Filter and sort members in a group
- Introduced in GitLab 12.6.
- Improved in GitLab 13.7.
- Feature flag removed in GitLab 13.8.
To find members in a group, you can sort, filter, or search.
Filter a group
Filter a group to find members. By default, all members in the group and subgroups are displayed.
- Go to the group and select Members.
- Above the list of members, in the Filter members box, enter filter criteria.
- To view members in the group only, select Membership = Direct.
- To view members of the group and its subgroups, select Membership = Inherited.
- To view members with two-factor authentication enabled or disabled, select 2FA = Enabled or Disabled.
Search a group
You can search for members by name, username, or email.
- Go to the group and select Members.
- Above the list of members, in the Filter members box, enter search criteria.
- To the right of the Filter members box, select the magnifying glass ({search}).
Sort members in a group
You can sort members by Account, Access granted, Max role, or Last sign-in.
- Go to the group and select Members.
- Above the list of members, on the top right, from the Account list, select the criteria to filter by.
- To switch the sort between ascending and descending, to the right of the Account list, select the arrow ({sort-lowest} or {sort-highest}).
Mention a group in an issue or merge request
When you mention a group in a comment, every member of the group gets a to-do item added to their To-do list.
- Open the MR or issue.
- In a comment, type
@
followed by the user, group, or subgroup namespace. For example,@alex
,@alex-team
, or@alex-team/marketing
. - Select Comment.
A to-do item is created for all the group and subgroup members.
Change the default branch protection of a group
Introduced in GitLab 12.9.
By default, every group inherits the branch protection set at the global level.
To change this setting for a specific group:
- Go to the group's Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- Select the desired option in the Default branch protection dropdown list.
- Click Save changes.
To change this setting globally, see Default branch protection.
NOTE: In GitLab Premium or higher, GitLab administrators can choose to disable group owners from updating the default branch protection.
Add projects to a group
There are two different ways to add a new project to a group:
-
Select a group, and then click New project. You can then continue creating your project.
-
While you are creating a project, select a group from the dropdown menu.
Specify who can add projects to a group
- Introduced in GitLab Premium 10.5.
- Brought to GitLab Starter in 10.7.
- Moved to GitLab Free in 11.10.
By default, Developers and Maintainers can create projects under a group.
To change this setting for a specific group:
- Go to the group's Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- Select the desired option in the Allowed to create projects dropdown list.
- Click Save changes.
To change this setting globally, see Default project creation protection.
Group activity analytics (PREMIUM)
- Introduced in GitLab Starter 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.
View group activity
You can view the most recent actions taken in a group.
- From the top menu, select Groups > Your Groups.
- Find the group and select it.
- From the left menu, select Group overview > Activity.
To view the activity feed in Atom format, select the RSS ({rss}) icon.
Share a group with another group
Introduced in GitLab 12.7.
Similar to how you share a project with a group, you can share a group with another group. Members get direct access to the shared group. This is not valid for inherited members.
To share a given group, for example, Frontend
with another group, for example,
Engineering
:
- Go to the
Frontend
group. - From the left menu, select Members.
- Select the Invite group tab.
- In the Select a group to invite list, select
Engineering
. - For the Max access level, select an access level.
- Select Invite.
All the members of the Engineering
group are added to the Frontend
group.
Manage group memberships via LDAP (PREMIUM SELF)
Group syncing allows LDAP groups to be mapped to GitLab groups. This provides more control over per-group user management. To configure group syncing, edit the group_base
DN ('OU=Global Groups,OU=GitLab INT,DC=GitLab,DC=org'
). This OU contains all groups that will be associated with GitLab groups.
Group links can be created by using either a CN or a filter. To create these group links, go to the group's Settings > LDAP Synchronization page. After configuring the link, it may take more than an hour for the users to sync with the GitLab group.
For more information on the administration of LDAP and group sync, refer to the main LDAP documentation.
NOTE: When you add LDAP synchronization, if an LDAP user is a group member and they are not part of the LDAP group, they are removed from the group.
Create group links via CN (PREMIUM SELF)
To create group links via CN:
- Select the LDAP Server for the link.
- As the Sync method, select
LDAP Group cn
. - In the LDAP Group cn field, begin typing the CN of the group. There is a dropdown menu with matching CNs in the configured
group_base
. Select your CN from this list. - In the LDAP Access section, select the permission level for users synced in this group.
- Select the Add Synchronization button.
Create group links via filter (PREMIUM SELF)
To create group links via filter:
- Select the LDAP Server for the link.
- As the Sync method, select
LDAP user filter
. - Input your filter in the LDAP User filter box. Follow the documentation on user filters.
- In the LDAP Access section, select the permission level for users synced in this group.
- Select the Add Synchronization button.
Override user permissions (PREMIUM SELF)
LDAP user permissions can be manually overridden by an administrator. To override a user's permissions:
- Go to your group's Members page.
- In the row for the user you are editing, select the pencil ({pencil}) icon.
- Select the brown Edit permissions button in the modal.
Now you can edit the user's permissions from the Members page.
Group wikis (PREMIUM)
- Introduced in GitLab Premium 13.5.
Group wikis work the same way as project wikis.
Group wikis can be edited by members with Developer permissions and above.
You can move group wiki repositories by using the Group repository storage moves API.
There are a few limitations compared to project wikis:
- Git LFS is not supported.
- Group wikis are not included in global search and Geo replication.
- Changes to group wikis don't show up in the group's activity feed.
For updates, follow the epic that tracks feature parity with project wikis.
Transfer a group
You can transfer groups in the following ways:
- 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.
When transferring groups, note:
- Changing a group's parent can have unintended side effects. See Redirects when changing repository paths.
- You can only transfer groups to groups you manage.
- 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 packages exist in any of the projects in the group, or in any of its subgroups.
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 may need to rename the group too. Both names and paths must be unique.
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):
- Go to your group's Settings > General page.
- Expand the Path, transfer, remove section.
- Under Change group URL, enter a new name.
- Select Change group URL.
WARNING: It is not possible to rename a namespace if it contains a project with Container Registry tags, because the project cannot be moved.
Use a custom name for the initial branch
- Introduced in GitLab 13.6.
By default, when you create a new project in GitLab, the initial branch is called master
.
For groups, a group owner can customize the initial branch name to something
else. This way, every new project created under that group from then on starts from the custom branch name rather than master
.
To use a custom name for the initial branch:
- Go to the group's Settings > Repository page.
- Expand the Default initial branch name section.
- Change the default initial branch to a custom name of your choice.
- Select Save changes.
Remove a group
To remove a group and its contents:
- Go to your group's Settings > General page.
- Expand the Path, transfer, remove section.
- In the Remove group section, select Remove group.
- Confirm the action.
This action removes the group. It also adds a background job to delete all projects in the group.
Specifically:
- In GitLab 12.8 and later, on Premium or higher tiers, this action adds a background job to mark a group for deletion. By default, the job schedules the deletion 7 days in the future. You can modify this waiting period through the instance settings.
- In GitLab 13.6 and later, if the user who sets up the deletion is removed from the group before the deletion happens, the job is cancelled, and the group is no longer scheduled for deletion.
Restore a group (PREMIUM)
Introduced in GitLab 12.8.
To restore a group that is marked for deletion:
- Go to your group's Settings > General page.
- Expand the Path, transfer, remove section.
- In the Restore group section, select Restore group.
Prevent a project from being shared with groups
Prevent projects in a group from sharing a project with another group to enable tighter control over project access.
To prevent a project from being shared with other groups:
- Go to the group's Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- Select Prevent sharing a project within <group_name> with other groups.
- Select Save changes.
Prevent members from being added to a group (PREMIUM)
As a group owner, you can prevent any new project membership for all projects in a group, allowing tighter control over project membership.
For example, if you want to lock the group for an Audit Event, you can guarantee that project membership cannot be modified during the audit.
To prevent members from being added to a group:
- Go to the group's Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- Under Member lock, select Prevent adding new members to project membership within this group.
- Select Save changes.
All users who previously had permissions can no longer add members to a group. API requests to add a new user to a project are not possible.
Restrict group access by IP address (PREMIUM)
- Introduced in GitLab Ultimate 12.0.
- Moved to GitLab Premium in 13.1.
NOTE: IP access restrictions are not functioning as expected on GitLab.com. If enabled, users cannot perform Git operations through SSH, or access projects in the UI. For more information, see this issue.
To ensure only people from your organization can access particular resources, you can restrict access to groups by IP address. This setting applies to all subgroups, projects, issues, and so on.
IP access restrictions can be configured at the group level only.
This restriction applies to:
- The GitLab UI.
- In GitLab 12.3 and later, the API.
- In GitLab 12.4 and later, Git actions via SSH.
Administrators and group owners are able to access the group regardless of the IP restriction.
To restrict group access by IP address:
- Go to the group’s Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- In the Allow access to the following IP addresses field, enter IP address ranges in CIDR notation.
- Select Save changes.
Restrict group access by domain (PREMIUM)
- Introduced in GitLab Premium 12.2.
- Support for specifying multiple email domains introduced added in GitLab 13.1.
You can prevent users with email addresses in specific domains from being added to a group.
To restrict group access by domain:
- Go to the group's Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- In the Restrict membership by email field, enter the domain names.
- Select Save changes.
Any time you attempt to add a new user, they are compared against this list.
Some domains cannot be restricted. These are the most popular public email domains, such as:
gmail.com
,yahoo.com
,aol.com
,icloud.com
hotmail.com
,hotmail.co.uk
,hotmail.fr
msn.com
,live.com
,outlook.com
NOTE: Domain restrictions apply to groups only. They do not prevent users from being added as members of projects owned by the restricted group.
Group file templates (PREMIUM)
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, as well as 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. Learn more about group-level project templates. (PREMIUM)
Enable group file template (PREMIUM)
To enable group file templates:
- Go to the group's Settings > General page.
- Expand the Templates section.
- Choose a project to act as the template repository.
- Select Save changes.
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:
- Go to the group's Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- Select Disable email notifications.
- 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.
This is particularly helpful for groups with a large number of users.
To disable group mentions:
- Go to the group's Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- Select Disable group mentions.
- Select Save changes.
Enable delayed project removal (PREMIUM)
Introduced in GitLab 13.2.
By default, projects in a group are deleted immediately. Optionally, on Premium or higher tiers, you can configure the projects in a group to be deleted after a delayed interval.
During this interval period, the projects are in a read-only state and can be restored, if required. The interval period defaults to 7 days, and can be modified by an administrator in the instance settings.
To enable delayed deletion of projects:
- Go to the group's Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- Check Enable delayed project removal.
- Select Save changes.
NOTE: The group setting for delayed deletion is not inherited by subgroups and has to be individually defined for each group.
Prevent project forking outside group (PREMIUM)
Introduced in GitLab 13.3.
By default, projects in a group can be forked. Optionally, on Premium or higher tiers, you can prevent the projects in a group from being forked outside of the current top-level group.
Previously this setting was available only for groups enforcing group managed account. This setting will be
removed from SAML setting page and migrated to group settings. In the interim period, both of these settings are taken into consideration.
If even one is set to true
then it will be assumed the group does not allow forking projects outside.
To enable prevent project forking:
- Go to the top-level group's Settings > General page.
- Expand the Permissions, LFS, 2FA section.
- Check Prevent project forking outside current group.
- Select Save changes.
Group push rules (PREMIUM)
- Introduced in GitLab Starter 12.8.
- Feature flag removed in GitLab 13.4.
Group push rules allow group maintainers to set push rules for newly created projects in the specific group.
To configure push rules for a group:
- Go to the groups's Push Rules page.
- Select the settings you want.
- Select Save Push Rules.
The group's new subgroups have push rules set for them based on either:
- The closest parent group with push rules defined.
- Push rules set at the instance level, if no parent groups have push rules defined.
Related topics
- Maximum artifacts size. (FREE SELF)
- Repositories analytics: View overall activity of all projects with code coverage. (PREMIUM)
- Contribution analytics: View the contributions (pushes, merge requests, and issues) of group members. (PREMIUM)
- Issue analytics: View a bar chart of your group's number of issues per month. (PREMIUM)
- Use GitLab as a dependency proxy for upstream Docker images.
- DORA4 Project Analytics API: View deployment frequency analytics. Introduced in GitLab Ultimate 13.9 as a Beta feature. (ULTIMATE SELF)
- Epics: Track groups of issues that share a theme. (ULTIMATE)
- Security Dashboard: View the vulnerabilities of all the projects in a group and its subgroups. (ULTIMATE)
- Insights: Configure insights like triage hygiene, issues created/closed per a given period, and average time for merge requests to be merged. (ULTIMATE)
- Webhooks.
- Kubernetes cluster integration.
- Audit Events. (PREMIUM)
- Pipelines quota: Keep track of the pipeline quota for the group.
- Integrations.
- Transfer a project into a group.
- Share a project with a group: Give all group members access to the project at once.
- Lock the sharing with group feature.
- Enforce two-factor authentication (2FA): Enforce 2FA for all group members.