Members of a project | GitLab Docs Skip to main content Go to GitLab Docs homepage What's new? What's new? Get free trial Toggle menu * Use GitLab * GitLab Duo * GitLab Orbit * Extend * Install * Administer * Subscribe * Contribute * Solutions Getting started Tutorials Manage your organization Tutorial: Set up your organization Namespaces Members Organizations Groups Import and migrate to GitLab Sharing projects and groups User account options GitLab.com settings Logs on GitLab.com Organize work with projects Plan and track work Manage authentication and authorization Use Git Manage your code Use CI/CD to build your application Secure your application Deploy and release your application Manage your infrastructure Monitor your application Analyze GitLab usage Release notes Feature support Find your GitLab version * GitLab Docs / * Use GitLab / * Manage your organization / * Members Help us learn about your current experience with the documentation. Take the survey . Members of a project * Tier : Free, Premium, Ultimate * Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated Members are the users and groups who have access to your project. Members can be added directly to your project or inherit access through groups. Each member has a role that determines what they can do in the project. Project members with the appropriate role can add users to projects, remove users from projects, and manage access requests to control access to project resources. Membership types History * Changed to display invited group members on the Members tab of the Members page in GitLab 16.10 with a feature flag named webui_members_inherited_users . Disabled by default. * Feature flag webui_members_inherited_users was enabled on GitLab.com and GitLab Self-Managed in GitLab 17.0. * Feature flag webui_members_inherited_users removed in GitLab 17.4. Members of invited groups displayed by default. Users can become members of a group or project directly or indirectly. Indirect membership can be inherited, shared, or inherited shared. Membership type Membership process Direct The user is added directly to the current group or project. Inherited The user is a member of a parent group that contains the current group or project. Shared The user is a member of a group invited to the current group or project. Inherited shared The user is a member of a group invited to an ancestor of the current group or project. Indirect An umbrella term for inherited, shared, or inherited shared members. %%{init: { "fontFamily": "GitLab Sans" }}%% flowchart RL accTitle: Membership types accDescr: Describes membership types and their inheritance subgraph Group A A(Direct member) B{{Shared member}} subgraph Project X H(Direct member) C{{Inherited member}} D{{Inherited shared member}} E{{Shared member}} end A-->|Inherited membership in Project X Direct membership in Group A|C end subgraph Group C G(Direct member) end subgraph Group B F(Direct member) end F-->|Group B invited to Group A|B B-->|Inherited membership in Project X Indirect membership in Group A|D G-->|Group C invited to Project X|E In the previous example: * Administrator is an inherited member from the demo group. * User 0 is an inherited member from the demo group. * User 1 is a shared member from the Acme group that is invited to this project. * User 2 is an inherited shared member from the Toolbox group that is invited to the demo group. * User 3 is a direct member added to this project. Security considerations Git is a distributed version control system (DVCS). Everyone who works with the source code has a local copy of the complete repository. In GitLab, every project member with the Reporter, Developer, Maintainer, or Owner role can clone the repository to create a local copy. Users can upload the full repository anywhere after they obtain a local copy, including: * Another project under their control. * A different server. * External hosting services. Access controls cannot prevent the intentional sharing of source code by users who already have access to the repository. All Git management platforms have this inherent characteristic of distributed version control systems. While you cannot prevent intentional sharing by authorized users, you can take the following steps to prevent unintentional sharing and information destruction: * Control who can add users to a project . * Use protected branches to prevent unauthorized force pushes. * Regularly review project membership and remove users who no longer require access. Add users to a project History * Access expiration date for direct members of subgroups and projects removed in GitLab 17.4. Add users to a project so they become direct members and have permission to perform actions. Prerequisites: * You must have the Maintainer or Owner role. * Group membership lock must be disabled. * For GitLab Self-Managed instances: * If new user accounts are disabled , an administrator must add the user. * If user invitations are not allowed , an administrator must add the user. * If administrator approval is enabled , an administrator must approve the invitation. To add a user to a project: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Manage > Members . * Select Invite members . * If the user: * Has a GitLab account, enter their username. * Doesn t have a GitLab account, enter their email address. * Select a default role or custom role . * Optional. Select an Access expiration date . From that date onward, the user can no longer access the project. If you selected an access expiration date, the project member gets an email notification seven days before their access expires. Maintainers have full permissions until their role expires, including the ability to extend their own access expiration date. * Select Invite . If you invited the user using their: * GitLab username, they are added to the members list. * Email address, an invitation is sent to their email address, and they are prompted to create an account. If the invitation is not accepted, GitLab sends reminder emails two, five, and ten days later. Unaccepted invites are automatically deleted after 90 days. Which roles you can assign The maximum role you can assign depends on whether you have the Maintainer or Owner role for the group. For example, the maximum role you can set is: * Owner ( 50 ), if you have the Owner role for the project. * Maintainer ( 40 ), if you have the Maintainer role on the project. The Owner role can be added for the group only. View project members To view members of a project: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Manage > Members . A table displays the member s: * Account name and username. * Source of their membership . For transparency, GitLab displays all membership sources of project members. Members who have multiple membership sources are displayed and counted as separate members. For example, if a member has been added to the project both directly and through inheritance, the member is displayed twice in the Members table, with different sources, and is counted as two individual members of the project. * Role in the project. * Expiration date of their project membership. * Activity related to their account. View users pending promotion If administrator approval for role promotions is turned on, membership requests that promote existing users into a billable role require administrator approval. To view users pending promotion: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Manage > Members . * Select the Role promotions tab. If the Role promotions tab is not displayed, the project has no pending promotions. Updating expiration and role If a user is: * A direct member of a project, the Expiration and Role fields can be updated directly on the project. * An inherited, shared, or inherited shared member, the Expiration and Role fields must be updated on the group that the member originates from. Share a project with a group Instead of adding users one by one, you can share a project with an entire group . Import members from another project You can import another project s direct members to your own project. Imported project members retain the same permissions as the project you import them from. Only direct members of a project are imported. Inherited or shared members of a project are not imported. Prerequisites: * You must have the Maintainer or Owner role. If the importing member s role for the target project is: * Maintainer, then members with the Owner role for the source project are imported with the Maintainer role. * Owner, then members with the Owner role for the source project are imported with the Owner role. To import a project s members: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Manage > Members . * Select Import from a project . * Select the project. You can view only the projects for which you re a maintainer. * Select Import project members . If the import is successful, a success message is displayed. To view the imported members on the Members tab, refresh the page. Remove a member from a project If a user is: * A direct member of a project, you can remove them directly from the project. * An inherited member from a parent group, you can only remove them from the parent group itself. Prerequisites: * The Maintainer or Owner role when removing a member that does not have the Owner role. * The Owner role when removing a member with the Owner role. To remove a member from a project: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Manage > Members . * Next to the project member you want to remove, select Remove member . * Optional. On the confirmation dialog, select the Also unassign this user from related issues and merge requests checkbox. * To prevent leaks of sensitive information from private projects, verify the member has not forked the private repository or created webhooks. Existing forks continue to receive changes from the upstream project, and webhooks continue to receive updates. You might also want to configure your project to prevent projects in a group from being forked outside their group . * Select Remove member . Ensure removed users cannot invite themselves back Users with the Maintainer or Owner role could exploit a race condition that allows them to rejoin groups or projects after an administrator removes them. To avoid this problem, GitLab administrators can: * Remove the malicious user session from the GitLab Rails console . * Impersonate the malicious user to: * Remove the user from the project. * Log the user out of GitLab. * Block the malicious user account. * Remove the malicious user account. * Change the password for the malicious user account. Filter and sort project members You can filter and sort members in a project. Display direct members * In the top bar, select Search or go to and find your project. * In the left sidebar, select Manage > Members . * In the Filter members box, select Membership = Direct . * Press Enter . Display indirect members * In the top bar, select Search or go to and find your project. * In the left sidebar, select Manage > Members . * In the Filter members box, select Membership = Indirect . * Press Enter . Search for members in a project To search for a project member: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Manage > Members . * In the search box, enter the member s name, username, or email. * Press Enter . Sort members in a project You can sort members in ascending or descending order by: * Account name * Access granted date * Role the members have in the project * User created date * Last activity date * Last sign-in date To sort members: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Manage > Members . * At the top of the member list, from the dropdown list, select the item you want to sort by. Request access to a project GitLab users can request to become a member of a project. * In the top bar, select Search or go to . * In the upper right, select the vertical ellipsis ( ) and select Request Access . An email is sent to the most recently active project Maintainers or Owners. Up to ten project Maintainers or Owners are notified. Any project Maintainer or Owner can approve or decline the request. Project Maintainers cannot approve Owner role access requests. If a project does not have any direct Owners or Maintainers, the most recently active Owners of the project s parent group receive the notification. Withdraw an access request to a project You can withdraw an access request to a project before the request is approved. To withdraw the access request: * In the top bar, select Search or go to . * Next to the project name, select Withdraw Access Request . Prevent users from requesting access to a project You can prevent users from requesting access to a project. Prerequisites: * You must have the Owner role for the project. * The project must be public. * In the top bar, select Search or go to and find your project. * In the left sidebar, select Settings > General . * Expand Visibility, project features, permissions . * Under Project visibility , ensure the Users can request access checkbox is not selected. * Select Save changes . Disabling the Allow users to request access setting prevents new access requests. Existing pending requests are not removed and can still be approved or denied. Membership and visibility rights Depending on their membership type, members of groups or projects are granted different visibility levels and rights into the group or project. The following table lists the membership and visibility rights of project members. Action Direct project member Inherited project member Direct shared project member Inherited shared project member Generate boards View issues of parent groups 1 View labels of parent groups View milestones of parent groups Be shared into other groups No No No Be imported into other projects No No No Share the project with other members Footnotes : * Users can view only issues of projects they have access to. The following table lists the membership and visibility rights of group members. Action Direct group member Inherited group member Direct shared group member Inherited shared group member Generate boards View issues of parent groups View labels of parent groups View milestones of parent groups In the following example, User is a: * Direct member of subgroup . * Inherited member of subsubgroup . * Indirect member of subgroup-2 and subgroup-3 . * Indirect inherited member of subsubgroup-2 and subsubgroup-3 . %%{init: { "fontFamily": "GitLab Sans" }}%% graph TD accTitle: Diagram of group inheritance accDescr: User inheritance, both direct and indirect through subgroups root --> subgroup --> subsubgroup root-2 --> subgroup-2 --> subsubgroup-2 root-3 --> subgroup-3 --> subsubgroup-3 subgroup -. shared .-> subgroup-2 -. shared .-> subgroup-3 User-. member .- subgroup class User user * Membership types * Security considerations * Add users to a project * Which roles you can assign * View project members * View users pending promotion * Updating expiration and role * Share a project with a group * Import members from another project * Remove a member from a project * Ensure removed users cannot invite themselves back * Filter and sort project members * Display direct members * Display indirect members * Search for members in a project * Sort members in a project * Request access to a project * Withdraw an access request to a project * Prevent users from requesting access to a project * Membership and visibility rights * Facebook * LinkedIn * Twitter * YouTube Company * About GitLab * View pricing * Try GitLab for free Feedback * View page source * Edit in Web IDE * Contribute to GitLab * Suggest updates Help & Community * Get certified * Get support * Post on the GitLab forum Resources * Terms * Privacy statement * Use of generative AI * Acceptable use of user licenses *