그룹을 사용하여 하나 이상의 관련 프로젝트를 동시에 관리합니다.

그룹 README 추가#

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

사전 요구사항:

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

그룹 README를 추가하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 그룹 README 섹션에서 README 추가를 선택합니다. 이 작업은 README.md 파일을 포함하는 새 프로젝트 gitlab-profile을 만듭니다.
4. README 만들기 프롬프트에서 만들기 및 README 추가를 선택합니다. Web IDE로 리디렉션되어 README 파일이 만들어집니다.
5. Web IDE에서 README.md 파일을 편집하고 커밋합니다.

그룹의 Owner 변경#

그룹의 Owner를 변경할 수 있습니다. 각 그룹에는 항상 Owner 권한을 가진 최소 한 명의 인간 구성원이 있어야 합니다. 내부 사용자("봇") 및 서비스 계정은 그룹의 유일한 Owner가 될 수 없습니다.

• 관리자로서:
  1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 관리 > 구성원을 선택합니다.
  3. 다른 구성원에게 Owner 권한을 부여합니다.
  4. 페이지를 새로 고침합니다. 이제 원래 Owner에서 Owner 권한을 제거할 수 있습니다.
• 현재 그룹의 Owner로서:
  1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 관리 > 구성원을 선택합니다.
  3. 다른 구성원에게 Owner 권한을 부여합니다.
  4. 새 Owner가 로그인하여 당신의 Owner 권한을 제거하도록 합니다.

그룹 경로 변경#

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

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

원래 네임스페이스의 소유권을 유지하고 URL 리디렉션을 보호하려면 새 그룹을 만들고 프로젝트를 그쪽으로 이전하세요.

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 고급 섹션을 확장합니다.
4. 그룹 URL 변경 아래에서 새 이름을 입력합니다.
5. 그룹 URL 변경을 선택합니다.

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

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

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

GitLab에서 새 프로젝트를 만들면 첫 번째 push와 함께 기본 브랜치가 만들어집니다. 그룹 Owner는 그룹의 프로젝트에 대한 초기 브랜치를 사용자 지정하여 그룹의 필요에 맞출 수 있습니다.

그룹 보관#

히스토리

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

그룹과 모든 서브그룹 및 프로젝트를 보관합니다. 보관되면 그룹과 그 내용은 읽기 전용이 되고, 그룹 데이터는 향후 참조를 위해 보존됩니다.

또한 보관된 그룹은:

• 그룹 페이지에 Archived 배지를 표시합니다
• Your work 페이지 및 탐색 페이지의 비활성 탭에 표시됩니다
• 다른 네임스페이스로 이전할 수 없습니다

알려진 제한 사항#

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

사전 요구사항:

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

그룹을 보관하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 고급을 확장합니다.
4. 그룹 보관 섹션에서 보관을 선택합니다.

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

1. 상단 바에서 검색 또는 이동을 선택합니다.
2. 내 모든 그룹 보기를 선택합니다.
3. 구성원 탭에서 보관하려는 그룹을 찾고 (⋮)를 선택합니다.
4. 보관을 선택합니다.

이 작업은 다른 목록 페이지에서도 사용 가능합니다.

그룹 보관 해제#

그룹과 모든 서브그룹 및 프로젝트를 보관 해제합니다. 그룹을 보관 해제하면:

• 그룹과 그 내용에서 읽기 전용 제한이 제거됩니다.
• 그룹과 서브그룹 및 프로젝트가 그룹 목록의 활성 또는 구성원 탭으로 돌아갑니다.

사전 요구사항:

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

그룹을 보관 해제하려면:

1. 보관된 그룹을 찾습니다.
   1. 상단 바에서 검색 또는 이동을 선택합니다.
   2. 내 모든 그룹 보기를 선택합니다.
   3. 비활성 탭에서 그룹을 선택합니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 고급 아래에서 확장을 선택합니다.
4. 그룹 보관 해제 섹션에서 보관 해제를 선택합니다.

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

1. 상단 바에서 검색 또는 이동을 선택합니다.
2. 내 모든 그룹 보기를 선택합니다.
3. 비활성 탭에서 보관 해제하려는 그룹을 찾고 (⋮)를 선택합니다.
4. 보관 해제를 선택합니다.

이 작업은 다른 목록 페이지에서도 사용 가능합니다.

그룹 이전#

히스토리

• GitLab 18.11에서 groups_and_projects_async_transfer라는 기능 플래그와 함께 그룹의 비동기 이전이 도입됨. 기본적으로 비활성화됨.

같은 GitLab 인스턴스에서 다른 위치로 이동하기 위해 그룹을 이전합니다. 다음을 수행할 수 있습니다:

• 서브그룹을 다른 상위 그룹으로 이전.
• 최상위 그룹을 서브그룹으로 변환.
• 서브그룹을 최상위 그룹으로 변환.

사전 요구사항:

• 소스 및 대상 그룹에 대한 Owner 권한.
• 대상 그룹에서 서브그룹 생성 활성화(해당하는 경우).

그룹을 이전하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 고급 섹션을 확장합니다.
4. 그룹 이전을 선택합니다.
5. 드롭다운 목록에서 그룹을 선택합니다.
6. 그룹 이전을 선택합니다.

이전을 확인하면:

• 그룹이 비동기적으로 이전됩니다.
• 이전이 완료되거나 실패한 후 확인 이메일이 전송됩니다.
• 이전 그룹 URL은 새 그룹 URL로 리디렉션됩니다. 페이지를 새로 고침하여 새 그룹 URL을 확인하세요. 대규모 그룹의 경우 이전이 완료될 때까지 기다린 후 대상 네임스페이스에서 그룹을 볼 수 있습니다.

그룹을 이전한 후 다음을 확인하세요:

• 로컬 저장소 원격을 새 URL로 업데이트합니다.
• 그룹 구성원 접근 및 권한을 확인합니다.
• 필요한 경우 패키지 구성을 업데이트합니다.
• CI/CD 파이프라인 및 통합을 테스트합니다.

다른 GitLab 인스턴스에 그룹을 복사해야 하는 경우, 직접 이전으로 그룹 마이그레이션을 수행하세요.

이전되는 데이터#

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

• 그룹의 모든 서브그룹 및 프로젝트
• 명시적 그룹 구성원 및 권한
• 그룹 설정 및 구성

알려진 이슈#

그룹을 이전할 때 다음 제한 사항을 염두에 두세요.

구성원 제한 사항:

• 상속된 구성원 자격은 손실됩니다. 직접 그룹 구성원만 이전됩니다.
• 그룹 Owner가 상속된 구성원 자격을 가지고 있는 경우, 그룹을 이전한 사용자가 새로운 Owner가 됩니다.

가시성 및 접근 제한 사항:

• 대상 상위 그룹의 가시성이 낮으면 모든 서브그룹 및 프로젝트의 가시성 설정이 대상 상위 그룹의 가시성과 일치하도록 조정됩니다.
• 저장소 URL이 변경됩니다. 새 위치를 가리키도록 로컬 저장소를 업데이트해야 합니다. 자세한 내용은 저장소 경로 변경을 참조하세요.

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

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

구독 제한 사항:

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

이메일 알림 비활성화#

서브그룹 및 프로젝트를 포함하여 그룹과 관련된 모든 이메일 알림을 비활성화할 수 있습니다.

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 확장합니다.
4. 이메일 알림 활성화 체크박스를 선택 해제합니다.

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

히스토리

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

머지 리퀘스트에서 코드에 코멘트를 달면 GitLab은 참여자에게 이메일 알림에 diff의 몇 줄을 포함합니다. 일부 조직 정책은 이메일을 덜 안전한 시스템으로 취급하거나 이메일을 위한 자체 인프라를 통제하지 않을 수 있습니다. 이는 소스 코드의 IP 또는 접근 제어에 위험을 초래할 수 있습니다.

사전 요구사항:

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

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능을 확장합니다.
4. diff 미리보기 포함을 선택 해제합니다.
5. 변경 사항 저장을 선택합니다.

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

히스토리

• GitLab 17.7에서 pat_expiry_inherited_members_notification이라는 플래그와 함께 상속된 그룹 구성원에게 알림 도입. 기본적으로 비활성화됨.
• GitLab 17.10에서 기능 플래그 pat_expiry_inherited_members_notification이 기본적으로 활성화됨.
• GitLab 17.11에서 기능 플래그 pat_expiry_inherited_members_notification 제거됨

다음 그룹 및 프로젝트 구성원은 곧 만료되는 액세스 토큰에 대한 알림 이메일을 받습니다:

• 그룹 액세스 토큰의 경우:
  • Owner 권한을 가진 구성원.
  • GitLab 17.7 이상에서, 해당 그룹 또는 상위 그룹에 적절한 설정이 구성된 경우, 그룹에 대한 Owner 권한을 상속받은 구성원.
• 프로젝트 액세스 토큰의 경우:
  • Maintainer 또는 Owner 권한을 가진 프로젝트 구성원.
  • GitLab 17.7 이상에서, 해당 그룹 또는 상위 그룹에 적절한 설정이 구성된 경우, 그룹에 속한 프로젝트에 대해 Maintainer 또는 Owner 권한을 상속받은 프로젝트 구성원.

그룹의 상속된 구성원에게 알림을 활성화할 수 있습니다:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능을 확장합니다.
4. 이 그룹 내의 그룹 및 프로젝트 액세스 토큰에 대한 만료 알림 이메일을 보낼 대상: 아래에서 그룹 또는 프로젝트의 모든 직접 및 상속 구성원을 선택합니다.
5. 선택 사항. 모든 서브그룹에 적용 체크박스를 선택합니다.
6. 변경 사항 저장을 선택합니다.

자세한 내용은 다음을 참조하세요:

• 그룹의 경우, 그룹 액세스 토큰 문서.
• 프로젝트의 경우, 프로젝트 액세스 토큰 문서.

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

히스토리

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

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

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 확장합니다.
4. 그룹 액세스 토큰 만료에 대한 추가 웹훅 트리거 추가 체크박스를 선택합니다.
5. 변경 사항 저장을 선택합니다.

그룹 멘션 비활성화#

사용자가 대화에 추가되는 것을 방지하고 그 사용자가 구성원인 그룹에 누군가 멘션할 때 알림을 받는 것을 막을 수 있습니다.

멘션이 비활성화된 그룹은 자동 완성 드롭다운 목록에 그에 따라 시각적으로 표시됩니다.

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

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 확장합니다.
4. 그룹 멘션 비활성화됨을 선택합니다.
5. 변경 사항 저장을 선택합니다.

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

히스토리

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

그룹의 엔터프라이즈 사용자가 개인 네임스페이스에 스니펫을 만드는 것을 방지할 수 있습니다. 비활성화되면 엔터프라이즈 사용자는 여전히 프로젝트 스니펫을 만들고 기존 개인 스니펫을 보고 편집할 수 있습니다.

사전 요구사항:

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

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 확장합니다.
4. 개인 스니펫 허용 체크박스를 선택 해제합니다.
5. 변경 사항 저장을 선택합니다.

그룹 초대 방지#

히스토리

• GitLab 18.0에서 도입됨. 기본적으로 비활성화됨.

GitLab.com에서 사용자가 최상위 그룹의 서브그룹이나 프로젝트에 새 구성원을 초대하는 기능을 제거할 수 있습니다. 이는 그룹 Owner의 초대 발송도 중지합니다. 사용자를 다시 초대할 수 있으려면 이 설정을 비활성화해야 합니다.

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

사전 요구사항:

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

그룹 초대를 방지하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 확장합니다.
4. 그룹/프로젝트 구성원 초대 비활성화를 선택합니다.
5. 변경 사항 저장을 선택합니다.

구성원을 CSV로 내보내기#

그룹 또는 서브그룹의 구성원 목록을 CSV로 내보낼 수 있습니다.

1. 상단 바에서 검색 또는 이동을 선택하고 그룹 또는 서브그룹을 찾습니다.
2. 관리 > 구성원을 선택합니다.
3. CSV로 내보내기를 선택합니다.
4. CSV 파일이 생성된 후 요청한 사용자에게 첨부 파일로 이메일로 전송됩니다.

출력은 직접 구성원과 상위 그룹에서 상속된 구성원을 나열합니다. 선택된 그룹에서 Minimal Access를 가진 구성원의 경우, 그들의 Max Role 및 Source는 서브그룹의 구성원 자격에서 파생됩니다. 이슈 390358은 그룹 구성원 CSV 내보내기 목록이 UI 구성원 목록과 일치하지 않는 문제에 대한 논의를 추적합니다.

제한된 접근#

히스토리

• GitLab 17.5에서 도입됨.
• GitLab 18.0에서 일반 공개.
• GitLab 18.7에서 그룹 공유 설정이 변경됨.

초과 요금을 방지하기 위해 제한된 접근을 사용합니다. 초과 요금은 구독의 좌석 수를 초과할 때 발생하며, 다음 분기 조정 때 지불해야 합니다.

제한된 접근을 켜면 구독에 남은 좌석이 없을 때 그룹에 새로운 청구 가능한 사용자를 추가할 수 없습니다.

제한된 접근 켜기#

사전 요구사항:

• 그룹에 대한 Owner 권한이 있어야 합니다.
• 그룹 또는 그 서브그룹이나 프로젝트 중 어떤 것도 외부에서 공유되어서는 안 됩니다.

제한된 접근을 켜려면:

1. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
2. 권한 및 그룹 기능을 확장합니다.
3. 좌석 제어 아래에서 제한된 접근을 선택합니다.

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

필요에 따라 그룹 및 서브그룹의 프로젝트 공유를 독립적으로 구성할 수 있습니다.

SAML, SCIM 및 LDAP를 통한 프로비저닝 동작#

히스토리

• GitLab 18.6에서 bso_minimal_access_fallback이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.
• GitLab 18.10에서 기본적으로 활성화됨.

제한된 접근이 활성화되고 구독 좌석이 없는 경우, SAML, SCIM 또는 LDAP를 통해 프로비저닝된 사용자는 구성된 접근 수준 대신 Minimal Access 권한이 할당됩니다. 이 동작은 GitLab.com 및 Self-Managed Ultimate에서 청구 가능한 좌석을 소비하지 않고 동기화가 계속될 수 있도록 보장합니다.

Minimal Access 권한을 가진 사용자는 인증하고 그룹에 접근할 수 있지만 제한된 권한을 갖습니다. 좌석이 사용 가능해지면 의도된 접근 수준으로 승격할 수 있습니다. 청구 가능한 권한을 가진 기존 사용자는 이 동작의 영향을 받지 않습니다.

좌석 사용량을 보고 Minimal Access를 가진 사용자를 관리할 수 있습니다.

휴면 엔터프라이즈 사용자 재활성화#

제한된 접근이 활성화되어 있고 좌석이 없는 경우, 다시 로그인을 시도하는 휴면 엔터프라이즈 사용자는 재활성화 대신 승인 대기 상태로 설정됩니다. 기존 그룹 및 프로젝트 구성원 자격은 보존됩니다. 그룹 Owner는 좌석이 사용 가능해지면 사용자를 승인할 수 있습니다.

비엔터프라이즈 휴면 구성원은 비활성화 대신 그룹 구성원 자격이 제거됩니다. SAML, SCIM 또는 LDAP 동기화를 통해 다시 참여할 때 프로비저닝 동작이 적용되며, 좌석이 없는 경우 Minimal Access 역할을 받습니다.

자세한 내용은 휴면 구성원 자동 제거를 참조하세요.

알려진 이슈#

제한된 접근을 켜면 다음과 같은 알려진 이슈가 발생하여 초과분이 발생할 수 있습니다:

• 다음과 같은 경우 여전히 좌석 수를 초과할 수 있습니다:
  • SAML, SCIM 또는 LDAP를 사용하여 새 구성원을 추가하고 구독의 좌석 수를 초과한 경우. Minimal Access 대안 기능이 활성화되면 사용자는 차단되는 대신 Minimal Access가 할당됩니다.
  • Owner 권한을 가진 여러 사용자가 동시에 구성원을 추가하는 경우.
  • 새로운 청구 가능한 구성원이 초대 수락을 지연하는 경우. 사용자를 초대하면 초대를 수락할 때까지 청구 가능한 좌석을 소비하지 않습니다. 초대된 사용자가 수락을 지연하면 그 동안 다른 사용자를 초대하고 추가할 수 있습니다. 지연된 사용자가 최종적으로 수락하면 청구 가능한 좌석을 소비하여, 이미 좌석 한도에 도달한 경우 초과분이 발생할 수 있습니다.
• 현재 구독보다 적은 수의 사용자로 GitLab 영업팀을 통해 구독을 갱신하면 초과 요금이 발생합니다. 이 요금을 피하려면 갱신이 시작되기 전에 추가 사용자를 제거하세요. 예를 들어, 사용자가 20명이고 15명에 대한 구독을 갱신하면 5명의 추가 사용자에 대한 초과분이 청구됩니다.

또한 제한된 접근이 표준 비초과 흐름을 차단할 수 있습니다:

• 청구 가능한 권한으로 업데이트되거나 추가된 서비스 봇이 잘못 차단됩니다.
• 이메일을 통해 기존 청구 가능한 사용자를 초대하거나 업데이트하는 것이 예기치 않게 차단됩니다.

그룹의 사용자 상한#

히스토리

• GitLab 16.3에서 GitLab.com에서 활성화됨.
• GitLab 17.1에서 일반 공개. 기능 플래그 saas_user_caps 제거됨.

GitLab Self-Managed의 사용자 상한에 대한 자세한 내용은 사용자 상한을 참조하세요.

청구 가능한 구성원 수가 사용자 상한에 도달하면 그룹 Owner가 새 구성원을 승인해야 합니다.

사용자 상한 기능이 활성화된 그룹은 그룹 및 서브그룹에 대해 그룹 공유가 비활성화됩니다.

그룹에 사용자 상한 설정#

사전 요구사항:

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

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 최상위 그룹에만 상한을 설정할 수 있습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능을 확장합니다.
4. 좌석 제어에서 사용자 상한 설정 체크박스를 선택하고 필드에 사용자 수를 입력합니다.
5. 변경 사항 저장을 선택합니다.

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

사용자 상한을 늘리면 대기 중인 구성원이 승인되지 않습니다.

그룹의 사용자 상한 제거#

사용자 상한을 제거하면 그룹에 추가할 수 있는 구성원 수에 제한이 없습니다.

사전 요구사항:

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

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능을 확장합니다.
4. 좌석 제어에서 개방 접근을 선택합니다.
5. 변경 사항 저장을 선택합니다.

사용자 상한을 줄이면 대기 중인 구성원이 승인되지 않습니다.

그룹의 대기 중인 구성원 승인#

청구 가능한 사용자 수가 사용자 상한에 도달하면 새 구성원은 대기 상태가 되어 승인을 받아야 합니다.

대기 중인 구성원은 청구 가능한 것으로 계산되지 않습니다. 구성원은 승인받고 더 이상 대기 상태가 아닌 경우에만 청구 가능한 것으로 계산됩니다.

사전 요구사항:

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

사용자 상한을 초과하여 대기 중인 구성원을 승인하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 사용 할당량을 선택합니다.
3. 좌석 탭의 알림 아래에서 대기 중인 승인 보기를 선택합니다.
4. 승인할 각 구성원에 대해 승인을 선택합니다.

알려진 이슈#

그룹, 서브그룹 또는 프로젝트가 외부에서 공유된 경우 사용자 상한을 활성화할 수 없습니다. 그룹, 서브그룹 또는 프로젝트가 외부에서 공유된 경우 계층 구조의 수준에 관계없이 네임스페이스 계층 외부에서 공유됩니다.

그룹, 서브그룹 또는 프로젝트가 외부에서 공유될 때 사용자 상한이 적용되도록 하려면 최상위 네임스페이스 내에서만 그룹 공유를 제한하세요. 최상위 네임스페이스 제한은 동일한 네임스페이스에서 초대를 허용하고 외부 공유로 인한 새 사용자(좌석) 추가를 방지합니다.

GitLab.com Ultimate에는 청구 가능한 사용자가 사용자 상한을 초과할 때 그룹에 게스트 사용자를 추가할 수 없는 알려진 이슈가 있습니다. 예를 들어, 사용자 상한이 5이고, 개발자가 3명, 게스트가 2명인 경우. 개발자를 2명 더 추가한 후에는 청구 가능한 좌석을 소비하지 않는 게스트 사용자라도 더 이상 사용자를 추가할 수 없습니다.

사용자 상한에서 제한된 접근으로 변경#

사용자 상한에서 제한된 접근으로 변경하면 모든 대기 중인 구성원(승인 대기 중인 구성원 및 초대된 구성원 모두)이 자동으로 제거됩니다. 사용자가 구성원으로 승인되도록 하려면 제한된 접근을 활성화하기 전에 대기 중인 구성원을 승인하거나 제거해야 합니다.

그룹 파일 템플릿#

그룹 파일 템플릿을 사용하여 그룹의 모든 프로젝트와 일반적인 파일 유형에 대한 템플릿 세트를 공유합니다. 인스턴스 템플릿 저장소와 유사합니다. 선택된 프로젝트는 해당 페이지에 문서화된 것과 동일한 명명 규칙을 따라야 합니다.

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

서브그룹과 직접 상위 그룹 모두에 대해 이 기능을 구성할 수 있습니다. 서브그룹의 프로젝트는 해당 서브그룹 및 직접 상위 그룹의 템플릿에 접근할 수 있습니다.

이슈 및 머지 리퀘스트에 대한 템플릿을 만드는 방법을 알아보려면 설명 템플릿을 참조하세요.

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

그룹 파일 템플릿 활성화#

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 템플릿 섹션을 확장합니다.
4. 템플릿 저장소 역할을 할 프로젝트를 선택합니다.
5. 변경 사항 저장을 선택합니다.

그룹 머지 검사 설정#

히스토리

• GitLab 15.9에서 support_group_level_merge_checks_setting이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.
• GitLab 16.9에서 일반 공개. 기능 플래그 support_group_level_merge_checks_setting 제거됨.

그룹 Owner는 모든 서브그룹 및 프로젝트에 적용되는 머지 리퀘스트 검사를 최상위 그룹에 설정할 수 있습니다.

설정이 서브그룹이나 프로젝트에 의해 상속된 경우, 상속받은 서브그룹이나 프로젝트에서 변경할 수 없습니다.

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

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

프로젝트 수준 설정도 참조하세요.

사전 요구사항:

• 그룹의 Owner여야 합니다.

이 설정을 활성화하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 머지 리퀘스트를 확장합니다.
4. 머지 검사 아래에서 파이프라인이 성공해야 함을 선택합니다. 이 설정은 파이프라인이 없는 경우 머지 리퀘스트가 병합되는 것도 방지합니다.
5. 변경 사항 저장을 선택합니다.

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

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

프로젝트 수준 설정도 참조하세요.

사전 요구사항:

• 그룹의 Owner여야 합니다.

이 동작을 변경하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 머지 리퀘스트를 확장합니다.
4. 머지 검사 아래에서:
   • 파이프라인이 성공해야 함을 선택합니다.
   • 스킵된 파이프라인은 성공한 것으로 간주를 선택합니다.
5. 변경 사항 저장을 선택합니다.

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

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

사전 요구사항:

• 그룹의 Owner여야 합니다.

이 설정을 활성화하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 머지 리퀘스트를 확장합니다.
4. 머지 검사 아래에서 모든 스레드가 해결되어야 함을 선택합니다.
5. 변경 사항 저장을 선택합니다.

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

그룹 승인 설정은 최상위 그룹의 서브그룹 및 프로젝트에 대한 프로젝트 머지 리퀘스트 승인 설정의 기본값을 정의합니다. 그룹에 대해 방지 설정을 활성화하면 해당 프로젝트 설정이 잠기고 프로젝트 Maintainer는 이를 변경할 수 없습니다. 방지 설정이 비활성화되면 프로젝트 Maintainer가 개별 프로젝트에 대해 구성할 수 있습니다. 자세한 내용은 인스턴스 또는 최상위 그룹에서 설정 캐스케이드를 참조하세요.

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 머지 리퀘스트 승인 섹션을 확장합니다.
4. 원하는 설정을 선택합니다.
5. 변경 사항 저장을 선택합니다.

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

그룹 활동 분석#

그룹의 경우 최근 90일 동안 만들어진 머지 리퀘스트, 이슈 및 구성원 수를 볼 수 있습니다.

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

그룹 활동 보기#

브라우저나 RSS 피드에서 그룹에서 수행된 가장 최근 작업을 볼 수 있습니다:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 관리 > 활동을 선택합니다.

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

GitLab 크레딧 사용자 데이터 표시#

히스토리

• GitLab 18.7에서 usage_billing_dev라는 플래그와 함께 사용자 데이터 표시를 허용하는 네임스페이스 설정이 도입됨. 기본적으로 활성화됨.
• GitLab 18.10에서 기능 플래그 usage_billing_dev가 제거됨.

사전 요구사항:

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

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

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 왼쪽 사이드바에서 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능 섹션을 확장합니다.
4. GitLab 크레딧 대시보드의 경우, 사용자 데이터 표시 체크박스를 선택합니다.
5. 변경 사항 저장을 선택합니다.