그룹을 사용하면 관련된 하나 이상의 프로젝트를 동시에 관리할 수 있습니다.

그룹 README 추가#

README 파일을 추가해 팀에 대한 정보를 제공하고 사용자가 프로젝트에 기여하도록 초대할 수 있습니다. README는 그룹 개요 페이지에 표시됩니다. 모든 그룹 멤버가 README를 보고 편집할 수 있습니다.

사전 요구 사항:

• 그룹 설정에서 README를 만들려면 그룹에 대한 Owner 권한이 있어야 합니다.

그룹 README를 추가하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Group README 섹션에서 Add README를 선택합니다. 이 작업은 README.md 파일이 들어 있는 새 프로젝트 gitlab-profile을 만듭니다.
4. README 생성 프롬프트에서 Create and add README를 선택합니다. Web IDE로 이동하며, 그곳에서 README 파일이 생성됩니다.
5. Web IDE에서 README.md 파일을 편집하고 커밋합니다.

그룹의 Owner 변경#

그룹의 Owner를 변경할 수 있습니다. 모든 그룹에는 Owner 권한을 가진 사람 멤버가 항상 최소 한 명 있어야 합니다. 내부 사용자("봇")와 서비스 계정은 그룹의 유일한 Owner가 될 수 없습니다.

• 관리자인 경우:
  1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. Manage > Members를 선택합니다.
  3. 다른 멤버에게 Owner 권한을 부여합니다.
  4. 페이지를 새로 고칩니다. 이제 기존 Owner에게서 Owner 권한을 제거할 수 있습니다.
• 현재 그룹의 Owner인 경우:
  1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
  2. Manage > Members를 선택합니다.
  3. 다른 멤버에게 Owner 권한을 부여합니다.
  4. 새 Owner가 로그인해 본인에게서 Owner 권한을 제거하도록 합니다.

그룹 경로 변경#

그룹 경로(그룹 URL)를 변경하면 의도하지 않은 부작용이 발생할 수 있습니다. 진행하기 전에 프로젝트와 API에서 리디렉션이 어떻게 동작하는지 확인합니다.

다른 그룹이나 사용자가 경로를 가져갈 수 있도록 경로를 변경하는 경우 그룹 이름도 변경해야 합니다. 이름과 경로는 모두 고유해야 합니다.

원래 네임스페이스의 소유권을 유지하고 URL 리디렉션을 보호하려면 대신 새 그룹을 만들어 그곳으로 프로젝트를 이전합니다.

그룹 경로(그룹 URL)를 변경하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Advanced 섹션을 확장합니다.
4. Change group URL에서 새 이름을 입력합니다.
5. Change group URL을 선택합니다.

그룹의 기본 브랜치 보호 변경#

GitLab 인스턴스의 관리자는 인스턴스의 모든 프로젝트에 대한 기본 브랜치 보호를 구성할 수 있습니다. 해당 인스턴스의 그룹은 전역 수준에서 설정된 브랜치 보호를 상속합니다. 그룹 Owner는 그룹의 프로젝트에 대해 인스턴스 설정을 재정의할 수 있습니다. GitLab Premium 또는 Ultimate에서는 인스턴스 관리자가 이 권한을 비활성화할 수 있습니다.

초기 브랜치에 사용자 지정 이름 사용#

GitLab에서 새 프로젝트를 만들면 첫 푸시와 함께 기본 브랜치가 생성됩니다. 그룹 Owner는 그룹의 필요에 맞게 그룹 프로젝트의 초기 브랜치를 사용자 지정할 수 있습니다.

그룹 보관#

히스토리

• GitLab 18.3에서 archive_group이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 18.9에서 일반 공개되었습니다. 기능 플래그 archive_group이 제거되었습니다.

그룹과 그 모든 하위 그룹 및 프로젝트를 보관합니다. 보관하면 그룹과 그 콘텐츠는 읽기 전용이 되고, 그룹 데이터는 나중에 참조할 수 있도록 보존됩니다.

또한 보관된 그룹은 다음과 같습니다.

• 그룹 페이지에 Archived 배지가 표시됩니다
• Your work 페이지와 Explore 페이지의 Inactive 탭에 나타납니다
• 다른 네임스페이스로 이전할 수 없습니다

알려진 제한 사항#

보관된 그룹의 이슈는 이슈 585677이 해결될 때까지 이슈 보드에 계속 표시됩니다.

사전 요구 사항:

• 관리자이거나 그룹에 대한 Owner 권한이 있어야 합니다.

그룹을 보관하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Advanced를 확장합니다.
4. Archive group 섹션에서 Archive를 선택합니다.

Your work 목록 보기에서 바로 그룹을 보관하려면:

1. 상단 바에서 Search or go to를 선택합니다.
2. View all my groups를 선택합니다.
3. Member 탭에서 보관할 그룹을 찾아 (⋮)를 선택합니다.
4. Archive를 선택합니다.

이 작업은 다른 목록 페이지에서도 사용할 수 있습니다.

그룹 보관 해제#

그룹과 그 모든 하위 그룹 및 프로젝트를 보관 해제합니다. 그룹을 보관 해제하면 다음과 같이 됩니다.

• 그룹과 그 콘텐츠에서 읽기 전용 제한이 제거됩니다.
• 그룹과 그 하위 그룹 및 프로젝트가 그룹 목록의 Active 탭 또는 Member 탭으로 돌아갑니다.

사전 요구 사항:

• 관리자이거나 그룹에 대한 Owner 권한이 있어야 합니다.

그룹을 보관 해제하려면:

1. 보관된 그룹을 찾습니다.
   1. 상단 바에서 Search or go to를 선택합니다.
   2. View all my groups를 선택합니다.
   3. Inactive 탭에서 그룹을 선택합니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Advanced에서 Expand를 선택합니다.
4. Unarchive group 섹션에서 Unarchive를 선택합니다.

Your work 목록 보기에서 바로 그룹을 보관 해제하려면:

1. 상단 바에서 Search or go to를 선택합니다.
2. View all my groups를 선택합니다.
3. Inactive 탭에서 보관 해제할 그룹을 찾아 (⋮)를 선택합니다.
4. Unarchive를 선택합니다.

이 작업은 다른 목록 페이지에서도 사용할 수 있습니다.

그룹 이전#

히스토리

• 그룹의 비동기 이전이 GitLab 18.11에서 groups_and_projects_async_transfer라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 19.4에서 일반 공개되었습니다. 기능 플래그 groups_and_projects_async_transfer가 제거되었습니다.

그룹을 이전하면 같은 GitLab 인스턴스 안에서 그룹을 한 위치에서 다른 위치로 옮길 수 있습니다. 다음을 수행할 수 있습니다.

• 하위 그룹을 다른 상위 그룹으로 이전합니다.
• 최상위 그룹을 하위 그룹으로 전환합니다.
• 하위 그룹을 최상위 그룹으로 전환합니다.

사전 요구 사항:

• 원본 그룹과 대상 그룹에 대한 Owner 권한.
• 대상 그룹에서 하위 그룹 생성 활성화(해당하는 경우).

그룹을 이전하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Advanced 섹션을 확장합니다.
4. Transfer group을 선택합니다.
5. 드롭다운 목록에서 그룹을 선택합니다.
6. Transfer group을 선택합니다.

이전을 확인한 뒤에는 다음과 같이 진행됩니다.

• 그룹이 비동기적으로 이전됩니다.
• 이전에 성공하면 Owner 또는 Maintainer 권한을 가진 사용자에게 확인 이메일이 전송됩니다.
• 이전에 실패하면 이메일이 전송되지 않습니다. 이전을 시작한 사용자에게 실패 사유가 담긴 할 일 항목이 생성됩니다.
• 이전 그룹 URL이 새 그룹 URL로 리디렉션됩니다. 페이지를 새로 고쳐 새 그룹 URL을 확인합니다. 대규모 그룹은 이전이 완료될 때까지 기다려야 대상 네임스페이스에서 그룹을 볼 수 있습니다.

그룹을 이전한 뒤에는 다음을 확인합니다.

• 로컬 리포지터리 리모트를 새 URL로 업데이트합니다.
• 그룹 멤버의 액세스와 권한을 확인합니다.
• 필요한 경우 패키지 구성을 업데이트합니다.
• CI/CD 파이프라인과 통합을 테스트합니다.

그룹을 다른 GitLab 인스턴스로 복사해야 한다면 직접 이전으로 그룹을 마이그레이션합니다.

이전되는 데이터#

그룹 이전에는 다음이 포함됩니다.

• 그룹에 속한 모든 하위 그룹과 프로젝트
• 명시적인 그룹 멤버십과 권한
• 그룹 설정과 구성

알려진 문제#

그룹을 이전할 때는 다음 제한 사항을 유념합니다.

멤버십 제한 사항:

• 상속된 멤버십은 사라집니다. 직접 그룹 멤버만 이전됩니다.
• 그룹 Owner가 상속된 멤버십을 가지고 있으면, 그룹을 이전한 사용자가 새 Owner가 됩니다.

가시성 및 액세스 제한 사항:

• 대상 상위 그룹의 가시성이 더 낮으면, 모든 하위 그룹과 프로젝트의 가시성 설정이 대상 상위 그룹의 가시성에 맞게 조정됩니다.
• 리포지터리 URL이 변경됩니다. 새 위치를 가리키도록 로컬 리포지터리를 업데이트해야 합니다. 자세한 내용은 리포지터리 페이지 변경을 참고합니다.

패키지 및 컨테이너 레지스트리 제한 사항:

• 대상 그룹이 최상위 그룹이고 그 그룹이나 하위 그룹의 프로젝트에 npm 이름 지정 규칙을 따르는 npm 패키지가 있으면 이전이 실패합니다.
• 그룹 엔드포인트를 사용하는 기존 패키지는 그룹 수준 엔드포인트 설정에 대한 해당 패키지의 단계에 따라 업데이트해야 합니다.
• 패키지가 인스턴스 수준 엔드포인트를 사용하고 그룹이 다른 최상위 그룹으로 이동된 경우에는 기존 패키지 이름을 업데이트해야 합니다.

구독 제한 사항:

• GitLab.com에서 구독이 있는 최상위 그룹은 이전할 수 없습니다. 이전을 가능하게 하려면 먼저 최상위 그룹의 구독을 제거해야 합니다. 그런 다음 최상위 그룹을 다른 최상위 그룹의 하위 그룹으로 이전할 수 있습니다.

Secrets Manager 제한 사항:

이메일 알림 비활성화#

그룹과 관련된 모든 이메일 알림을 비활성화할 수 있으며, 여기에는 그룹의 하위 그룹과 프로젝트가 포함됩니다.

이메일 알림을 비활성화하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Permissions and group features 섹션을 확장합니다.
4. Enable email notifications 체크박스를 선택 해제합니다.

이메일 알림에서 diff 미리보기 비활성화#

히스토리

• GitLab 15.6에서 diff_preview_in_email이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 17.1에서 일반 공개되었습니다. 기능 플래그 diff_preview_in_email이 제거되었습니다.

머지 리퀘스트에서 코드에 댓글을 달면 GitLab은 참여자에게 보내는 이메일 알림에 diff 몇 줄을 포함합니다. 일부 조직의 정책은 이메일을 보안성이 낮은 시스템으로 취급하거나, 이메일용 인프라를 자체적으로 통제하지 못할 수 있습니다. 이는 소스 코드의 IP나 접근 제어에 위험이 될 수 있습니다.

사전 요구 사항:

• 그룹에 대한 Owner 권한이 있어야 합니다.

그룹의 모든 프로젝트에 대해 diff 미리보기를 비활성화하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Permissions and group features를 확장합니다.
4. Include diff previews를 선택 해제합니다.
5. Save changes를 선택합니다.

그룹 및 프로젝트 액세스 토큰 만료 이메일#

히스토리

• 상속된 그룹 멤버에 대한 알림이 GitLab 17.7에서 pat_expiry_inherited_members_notification이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• 기능 플래그 pat_expiry_inherited_members_notification이 GitLab 17.10에서 기본적으로 활성화되었습니다.
• 기능 플래그 pat_expiry_inherited_members_notification이 GitLab 17.11에서 제거되었습니다.

다음 그룹 및 프로젝트 멤버는 곧 만료되는 액세스 토큰에 대한 알림 이메일을 받습니다.

• 그룹 액세스 토큰의 경우:
  • Owner 권한이 있는 멤버.
  • GitLab 17.7 이상에서는 그룹에 대한 Owner 권한을 상속한 멤버로, 해당 그룹이나 그 상위 그룹에 관련 설정이 구성되어 있는 경우.
• 프로젝트 액세스 토큰의 경우:
  • Maintainer 또는 Owner 권한이 있는 프로젝트 멤버.
  • GitLab 17.7 이상에서는 프로젝트가 그룹에 속해 Maintainer 또는 Owner 권한을 상속한 프로젝트 멤버로, 해당 그룹이나 그 상위 그룹에 관련 설정이 구성되어 있는 경우.

그룹의 상속된 멤버에게 보내는 알림을 활성화할 수 있습니다.

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Permissions and group features를 확장합니다.
4. Expiry notification emails about group and project access tokens within this group should be sent to: 아래에서 All direct and inherited members of the group or project를 선택합니다.
5. 선택 사항. Enforce for all subgroups 체크박스를 선택합니다.
6. Save changes를 선택합니다.

자세한 내용은 다음을 참고합니다.

• 그룹은 그룹 액세스 토큰 문서.
• 프로젝트는 프로젝트 액세스 토큰 문서.

그룹 액세스 토큰 만료에 대한 추가 웹훅 트리거 추가#

히스토리

• 프로젝트 및 그룹 액세스 토큰 웹훅의 60일 및 30일 트리거가 GitLab 17.9에서 extended_expiry_webhook_execution_setting이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 17.10에서 일반 공개되었습니다. 기능 플래그 extended_expiry_webhook_execution_setting이 제거되었습니다.

GitLab은 그룹 토큰이 만료되기 전에 여러 차례 만료 이메일을 보내고 관련 웹훅을 트리거합니다. 기본적으로 이 웹훅은 토큰이 만료되기 7일 전에 트리거됩니다.

토큰이 만료되기 60일 전과 30일 전에도 이 웹훅이 트리거되도록 구성하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Permissions and group features 섹션을 확장합니다.
4. Add additional webhook triggers for group access token expiration 체크박스를 선택합니다.
5. Save changes를 선택합니다.

그룹 멘션 비활성화#

누군가 그룹을 멘션할 때 그 그룹의 멤버인 사용자가 대화에 추가되어 알림을 받는 것을 방지할 수 있습니다.

멘션이 비활성화된 그룹은 자동 완성 드롭다운 목록에 그에 맞게 표시됩니다.

이러한 시각적 단서는 사용자가 많은 그룹에서 특히 유용합니다.

그룹 멘션을 비활성화하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Permissions and group features 섹션을 확장합니다.
4. Group mentions are disabled를 선택합니다.
5. Save changes를 선택합니다.

엔터프라이즈 사용자의 개인 스니펫 제한#

히스토리

• GitLab 18.5에서 allow_personal_snippets_setting이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 18.9에서 일반 공개되었습니다. 기능 플래그 allow_personal_snippets_setting이 제거되었습니다.

그룹의 엔터프라이즈 사용자가 개인 네임스페이스에 스니펫을 만들지 못하도록 할 수 있습니다. 비활성화하면 엔터프라이즈 사용자는 프로젝트 스니펫은 계속 만들 수 있고, 기존 개인 스니펫은 보고 편집할 수 있습니다.

사전 요구 사항:

• 그룹에 대한 Owner 권한이 있어야 합니다.

엔터프라이즈 사용자의 개인 스니펫을 제한하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Permissions and group features 섹션을 확장합니다.
4. Allow personal snippets 체크박스를 선택 해제합니다.
5. Save changes를 선택합니다.

그룹 초대 방지#

히스토리

• GitLab 18.0에서 도입되었습니다. 기본적으로 비활성화되어 있습니다.

GitLab.com에서는 사용자가 최상위 그룹의 하위 그룹이나 프로젝트에 새 멤버를 초대하는 기능을 없앨 수 있습니다. 이렇게 하면 그룹 Owner도 초대를 보낼 수 없습니다. 사용자를 다시 초대하려면 이 설정을 먼저 비활성화해야 합니다.

GitLab Self-Managed 및 GitLab Dedicated 인스턴스에서는 인스턴스 전체에 대해 사용자 초대를 방지할 수 있습니다. 자세한 내용은 그룹 및 프로젝트 초대 방지를 참고합니다.

사전 요구 사항:

• 그룹에 대한 Owner 권한이 있어야 합니다.

그룹 초대를 방지하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Permissions and group features 섹션을 확장합니다.
4. Disable Group/Project members invitation을 선택합니다.
5. Save changes를 선택합니다.

멤버를 CSV로 내보내기#

그룹 또는 하위 그룹의 멤버 목록을 CSV로 내보낼 수 있습니다.

1. 상단 바에서 Search or go to를 선택하고 그룹 또는 하위 그룹을 찾습니다.
2. Manage > Members를 선택합니다.
3. Export as CSV를 선택합니다.
4. CSV 파일이 생성되면 요청한 사용자에게 첨부 파일로 이메일이 전송됩니다.

출력에는 직접 멤버와 상위 그룹에서 상속된 멤버가 나열됩니다. 선택한 그룹에서 Minimal Access인 멤버의 Max Role과 Source는 하위 그룹의 멤버십에서 파생됩니다. 이슈 390358에서 그룹 멤버 CSV 내보내기 목록이 UI 멤버 목록과 일치하지 않는 문제에 대한 논의를 추적합니다.

제한된 접근 켜기#

사전 요구 사항:

• 그룹에 대한 Owner 권한이 있어야 합니다.
• 그룹 또는 그 하위 그룹이나 프로젝트가 외부에 공유되어 있지 않아야 합니다.

제한된 접근을 켜려면:

1. 왼쪽 사이드바에서 Settings > General을 선택합니다.
2. Permissions and group features를 확장합니다.
3. Seat control 아래에서 Restricted access를 선택합니다.

제한된 접근을 켜면 그룹 계층 외부의 그룹 초대 방지 설정이 자동으로 켜집니다.

필요에 따라 그룹 및 그 하위 그룹의 프로젝트 공유는 계속 독립적으로 구성할 수 있습니다.

그룹에 사용자 상한 설정#

사전 요구 사항:

• 그룹에 대한 Owner 권한이 할당되어 있어야 합니다.

사용자 상한을 설정하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다. 상한은 최상위 그룹에만 설정할 수 있습니다.
2. Settings > General을 선택합니다.
3. Permissions and group features를 확장합니다.
4. Seat control에서 Set user cap 체크박스를 선택하고 필드에 사용자 수를 입력합니다.
5. Save changes를 선택합니다.

그룹에 이미 사용자 상한 값보다 많은 사용자가 있어도 사용자는 제거되지 않습니다. 다만 승인 없이는 더 추가할 수 없습니다.

사용자 상한을 늘려도 대기 중인 멤버가 승인되지는 않습니다.

사용자 상한을 설정하면 그룹 계층 외부의 그룹 초대 방지 설정이 자동으로 켜집니다.

그룹의 사용자 상한 제거#

사용자 상한을 제거하면 그룹에 추가할 수 있는 멤버 수에 제한이 없어집니다.

사전 요구 사항:

• 그룹에 대한 Owner 권한이 할당되어 있어야 합니다.

사용자 상한을 제거하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Permissions and group features를 확장합니다.
4. Seat control에서 Open access를 선택합니다.
5. Save changes를 선택합니다.

그룹의 대기 중인 멤버 승인#

청구 대상 사용자 수가 사용자 상한에 도달하면 새 멤버는 대기 상태가 되며 승인을 받아야 합니다.

대기 중인 멤버는 청구 대상으로 계산되지 않습니다. 멤버는 승인을 받아 더 이상 대기 상태가 아닐 때에만 청구 대상으로 계산됩니다.

사전 요구 사항:

• 그룹에 대한 Owner 권한이 할당되어 있어야 합니다.

사용자 상한을 초과해 대기 중인 멤버를 승인하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > Usage quotas를 선택합니다.
3. Seats 탭의 알림 아래에서 View pending approvals를 선택합니다.
4. 승인할 멤버마다 Approve를 선택합니다.

내장 프로젝트 템플릿 제어#

히스토리

• GitLab 19.0에서 use_built_in_project_templates_enabled라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 19.2에서 일반 공개되었습니다. 기능 플래그 use_built_in_project_templates_enabled가 제거되었습니다.

내장 프로젝트 템플릿은 새 프로젝트에 스타터 파일을 채웁니다. 사용자가 그룹에서 프로젝트를 만들 때 이러한 템플릿을 사용할 수 있게 할지 제어할 수 있습니다. 또한 모든 하위 그룹에 그 선택을 적용할 수 있습니다.

이 설정은 계단식 상속을 사용합니다.

• 그룹은 가장 가까운 상위 그룹 또는 인스턴스에서 설정을 상속합니다.
• 그룹에 설정된 값은 상속된 값을 재정의합니다.
• 그룹에 대해 설정을 적용하면 모든 하위 그룹이 이를 상속하고 변경할 수 없습니다.
• 그룹의 설정을 변경하면 새 값이 모든 하위 그룹으로 전파됩니다.

사전 요구 사항:

• 그룹에 대한 Owner 권한이 있어야 합니다.

그룹의 내장 프로젝트 템플릿을 제어하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Built-in project templates를 확장합니다.
4. Enable built-in project templates 체크박스를 선택하거나 선택 해제합니다.
5. 선택 사항. 하위 그룹이 이 설정을 변경하지 못하게 하려면 Enforce for all subgroups 체크박스를 선택합니다.
6. Save changes를 선택합니다.

관리자가 인스턴스에 대해 이 설정을 적용했거나 상위 그룹이 하위 그룹에 대해 적용한 경우, 설정이 잠기고 변경할 수 없습니다.

그룹 파일 템플릿#

그룹 파일 템플릿을 사용하면 일반적인 파일 형식에 대한 템플릿 모음을 그룹의 모든 프로젝트와 공유할 수 있습니다. 이는 인스턴스 템플릿 리포지터리와 유사합니다. 선택한 프로젝트는 해당 페이지에 문서화된 것과 같은 이름 지정 규칙을 따라야 합니다.

템플릿 소스로는 그룹에 있는 프로젝트만 선택할 수 있습니다. 여기에는 그룹과 공유된 프로젝트가 포함되지만, 구성 대상 그룹의 하위 그룹이나 상위 그룹에 있는 프로젝트는 제외됩니다.

이 기능은 하위 그룹과 직계 상위 그룹 모두에 구성할 수 있습니다. 하위 그룹의 프로젝트는 해당 하위 그룹과 모든 직계 상위 그룹의 템플릿에 액세스할 수 있습니다.

이슈와 머지 리퀘스트용 템플릿을 만드는 방법은 설명 템플릿을 참고합니다.

그룹을 템플릿 소스로 설정해 그룹 수준에서 프로젝트 템플릿을 정의합니다. 자세한 내용은 그룹 수준 프로젝트 템플릿을 참고합니다.

그룹 파일 템플릿 활성화#

그룹 파일 템플릿을 활성화하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Templates 섹션을 확장합니다.
4. 템플릿 리포지터리로 사용할 프로젝트를 선택합니다.
5. Save changes를 선택합니다.

그룹 머지 검사 설정#

그룹 Owner는 최상위 그룹에 머지 리퀘스트 검사를 설정할 수 있으며, 이는 모든 하위 그룹과 프로젝트에 적용됩니다.

하위 그룹이나 프로젝트가 설정을 상속한 경우, 상속한 하위 그룹이나 프로젝트에서는 해당 설정을 변경할 수 없습니다.

병합을 위한 성공적인 파이프라인 필요#

그룹의 모든 하위 프로젝트가 병합 전에 완료된 성공 파이프라인을 요구하도록 구성할 수 있습니다.

프로젝트 수준 설정도 참고합니다.

사전 요구 사항:

• 그룹의 Owner여야 합니다.

이 설정을 활성화하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Merge requests를 확장합니다.
4. Merge checks에서 Pipelines must succeed를 선택합니다. 이 설정은 파이프라인이 없는 경우에도 머지 리퀘스트가 병합되지 않도록 합니다.
5. Save changes를 선택합니다.

스킵된 파이프라인 후 병합 허용#

스킵된 파이프라인이 머지 리퀘스트의 병합을 막지 않도록 구성할 수 있습니다.

프로젝트 수준 설정도 참고합니다.

사전 요구 사항:

• 그룹의 Owner여야 합니다.

이 동작을 변경하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Merge requests를 확장합니다.
4. Merge checks에서 다음을 수행합니다.
   • Pipelines must succeed를 선택합니다.
   • Skipped pipelines are considered successful를 선택합니다.
5. Save changes를 선택합니다.

모든 스레드가 해결될 때까지 병합 방지#

모든 스레드가 해결될 때까지 머지 리퀘스트가 병합되지 않도록 할 수 있습니다. 이 설정을 활성화하면 그룹의 하위 프로젝트에서 열린 스레드가 하나 이상 있는 머지 리퀘스트에 열린 스레드 수가 주황색으로 표시됩니다.

사전 요구 사항:

• 그룹의 Owner여야 합니다.

이 설정을 활성화하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Merge requests를 확장합니다.
4. Merge checks에서 All threads must be resolved를 선택합니다.
5. Save changes를 선택합니다.

머지 리퀘스트 API에서 커밋 SHA 요구#

히스토리

• GitLab 19.2에서 도입되었습니다. 새 그룹에는 기본적으로 활성화되어 있습니다.
• 그룹 및 인스턴스 설정 UI가 GitLab 19.3에서 도입되었습니다.
• GitLab 19.2.6, GitLab 19.3.2, GitLab 19.4에서 새 그룹에 대해 기본적으로 비활성화되도록 변경되었습니다.

검토된 커밋만 병합되도록 머지 리퀘스트 API에서 커밋 SHA를 요구합니다. 이 설정을 활성화하면 GitLab은 sha 파라미터를 생략한 머지 리퀘스트 병합 엔드포인트 호출을 거부하고 400 오류를 반환합니다. sha 파라미터가 소스 브랜치의 현재 HEAD와 일치하지 않으면 병합이 실패합니다.

이 설정은 기본적으로 비활성화되어 있습니다.

사전 요구 사항:

• 그룹에 대한 Owner 권한.

머지 리퀘스트 API에서 커밋 SHA를 요구하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Merge requests를 확장합니다.
4. Require commit SHA on merge requests API 체크박스를 선택합니다.
5. 선택 사항. 모든 하위 그룹에 이 설정을 적용하고 하위 그룹이 변경하지 못하게 하려면 Enforce for all subgroups 체크박스를 선택합니다.
6. Save changes를 선택합니다.

관리자는 이 설정에 대해 인스턴스 전체 기본값을 설정할 수 있고, 선택적으로 이를 적용해 새 그룹이 재정의하지 못하게 할 수 있습니다.

사전 요구 사항:

• 인스턴스에 대한 관리자 액세스 권한.

모든 그룹에 대한 기본값을 설정하려면:

1. 왼쪽 사이드바 아래쪽에서 Admin을 선택합니다.
2. Settings > General을 선택합니다.
3. Merge requests를 확장합니다.
4. Require commit SHA on merge requests API 체크박스를 선택합니다.
5. 선택 사항. 인스턴스의 모든 신규 및 기존 그룹에 이 설정을 적용하고 그룹이 변경하지 못하게 하려면 Enforce this setting for all groups on this instance를 선택합니다.
6. Save changes를 선택합니다.

그룹 머지 리퀘스트 승인 설정#

그룹 승인 설정은 최상위 그룹의 하위 그룹과 프로젝트에서 프로젝트 머지 리퀘스트 승인 설정의 기본값을 정의합니다. 그룹에 방지 설정을 활성화하면 동등한 프로젝트 설정이 잠기고 프로젝트 Maintainer는 이를 변경할 수 없습니다. 방지 설정을 비활성화된 상태로 두면 프로젝트 Maintainer가 개별 프로젝트에 대해 구성할 수 있습니다. 자세한 내용은 인스턴스 또는 최상위 그룹에서 설정 계단식 적용을 참고합니다.

그룹의 머지 리퀘스트 승인 설정을 보려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Merge request approvals 섹션을 확장합니다.
4. 원하는 설정을 선택합니다.
5. Save changes를 선택합니다.

승인 설정은 승인 규칙과 혼동하지 않아야 합니다. 그룹에 머지 리퀘스트 승인 규칙을 설정하는 기능에 대한 지원은 에픽 4367에서 추적합니다.

그룹 활동 분석#

그룹에서 지난 90일 동안 생성된 머지 리퀘스트, 이슈, 멤버의 수를 확인할 수 있습니다.

그룹 위키의 변경 사항은 그룹 활동 분석에 나타나지 않습니다.

그룹 활동 보기#

브라우저나 RSS 피드에서 그룹에서 이루어진 가장 최근 작업을 확인할 수 있습니다.

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Manage > Activity를 선택합니다.

Atom 형식으로 활동 피드를 보려면 RSS ([rss]) 아이콘을 선택합니다.

GitLab Credits 사용자 데이터 표시#

히스토리

• 사용자 데이터 표시를 허용하는 네임스페이스 설정이 GitLab 18.7에서
• 기능 플래그 usage_billing_dev가 GitLab 18.10에서 제거되었습니다.

사전 요구 사항:

• 그룹 Owner여야 합니다.
• 데이터를 보려는 그룹이 최상위 그룹이어야 합니다.

GitLab Credits 대시보드에 사용자 데이터를 표시하려면:

1. 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Permissions and group features 섹션을 확장합니다.
4. GitLab Credits dashboard에서 Display user data 체크박스를 선택합니다.
5. Save changes를 선택합니다.