히스토리

• GitLab 17.4에서 importer_user_mapping 및 bulk_import_importer_user_mapping이라는 플래그와 함께 직접 전송에 대해 도입되었습니다. 기본값으로 비활성화됩니다.
• GitLab 17.6에서 importer_user_mapping 및 gitea_user_mapping이라는 플래그와 함께 Gitea에 대해, importer_user_mapping 및 github_user_mapping이라는 플래그와 함께 GitHub에 대해 도입되었습니다. 기본값으로 비활성화됩니다.
• GitLab 17.7에서 importer_user_mapping 및 bitbucket_server_user_mapping이라는 플래그와 함께 Bitbucket Server에 대해 도입되었습니다. 기본값으로 비활성화됩니다.
• GitLab 17.7에서 직접 전송에 대해 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
• GitLab 17.7에서 Bitbucket Server, Gitea, GitHub에 대해 GitLab.com에서 활성화되었습니다.
• GitLab 17.8에서 Bitbucket Server, Gitea, GitHub에 대해 GitLab Self-Managed에서 활성화되었습니다.
• GitLab 18.3에서 개인 네임스페이스로 임포트할 때 개인 네임스페이스 소유자에게 기여를 재할당하는 기능이 user_mapping_to_personal_namespace_owner라는 플래그와 함께 도입되었습니다. 기본값으로 비활성화됩니다.
• GitLab 18.4에서 직접 전송에 대해 일반 공개되었습니다. 기능 플래그 bulk_import_importer_user_mapping이 제거되었습니다.
• GitLab 18.5에서 서비스 계정, 프로젝트 봇, 그룹 봇에 기여를 재할당하는 기능이 user_mapping_service_account_and_bots라는 플래그와 함께 도입되었습니다. 기본값으로 활성화됩니다.
• GitLab 18.6에서 Gitea에 대해 일반 공개되었습니다. 기능 플래그 gitea_user_mapping이 제거되었습니다.
• GitLab 18.6에서 개인 네임스페이스로 임포트할 때 개인 네임스페이스 소유자에게 기여를 재할당하는 기능이 일반 공개되었습니다. 기능 플래그 user_mapping_to_personal_namespace_owner가 제거되었습니다.
• GitLab 18.8에서 github_user_mapping 기능 플래그가 제거되었습니다.
• GitLab 18.10에서 user_mapping_service_account_and_bots 기능 플래그가 제거되었습니다.

마이그레이션 후 매핑을 사용하면 소스 인스턴스의 사용자 기여와 멤버십이 처음에는 대상 인스턴스의 실제 사용자가 아닌 플레이스홀더 사용자에게 할당됩니다.

실제 사용자에게 할당을 미룰 수 있어 임포트를 검토하고 올바른 사용자에게 기여를 재할당할 시간을 얻을 수 있습니다. 이 프로세스는 매핑 프로세스에 대한 제어를 유지하면서 정확한 속성을 보장합니다.

마이그레이션 후 사용자 기여 및 멤버십 매핑은 다음에서의 마이그레이션에 대해 기본값으로 사용할 수 있습니다:

• 직접 전송을 사용하는 GitLab
• GitHub
• Bitbucket Server
• Gitea

개인 네임스페이스로 프로젝트를 임포트할 때 사용자 기여 매핑 및 멤버십 매핑이 지원되지 않으며, 모든 기여가 개인 네임스페이스 소유자에게 할당됩니다. 이러한 기여는 재할당할 수 없습니다.

사전 요구 사항#

• 사용자 제한에 따라 사용자 수를 계획합니다.
• GitLab.com으로 임포트하는 경우 유료 네임스페이스를 설정합니다.
• GitLab.com으로 임포트하고 GitLab.com 그룹의 SAML SSO를 사용하는 경우 모든 사용자가 SAML ID를 GitLab.com 계정에 연결했는지 확인합니다.

마이그레이션 후 매핑 워크플로#

마이그레이션 후 매핑을 사용할 때 GitLab은 임포트한 모든 멤버십과 기여를 플레이스홀더 사용자에게 매핑합니다. 플레이스홀더 사용자는 소스 인스턴스에 동일한 이메일 주소를 가진 사용자가 있더라도 대상 인스턴스에 생성됩니다. 대상 인스턴스에서 기여를 재할당할 때까지 모든 기여는 플레이스홀더 사용자와 연결됩니다.

임포트가 완료되고 결과를 검토한 후 다음과 같이 매핑을 업데이트할 수 있습니다:

• 대상 인스턴스의 기존 사용자에게 멤버십과 기여를 재할당합니다. 소스와 대상 인스턴스에서 서로 다른 이메일 주소를 가진 사용자의 멤버십과 기여를 매핑할 수 있습니다.
• 대상 인스턴스에 새 사용자를 생성하고 멤버십과 기여를 재할당합니다.

역사적 컨텍스트를 보존하기 위해 특정 기여를 플레이스홀더 사용자에게 계속 할당할 수도 있습니다.

대상 인스턴스의 사용자에게 기여를 재할당하면 사용자는 다음 중 하나를 선택할 수 있습니다:

• 재할당을 수락합니다. 재할당 프로세스는 몇 분이 걸릴 수 있습니다. 이후에 동일한 소스 인스턴스에서 대상 인스턴스의 동일한 최상위 그룹 또는 하위 그룹으로 임포트할 때 기여가 자동으로 사용자에게 매핑됩니다.
• 재할당을 거부합니다.

엔터프라이즈 사용자#

히스토리

• GitLab 18.0에서 도입되었습니다.

최상위 그룹에 엔터프라이즈 사용자가 하나 이상 있으면 조직의 엔터프라이즈 사용자에게만 기여를 재할당할 수 있습니다.

즉, 조직 외부의 사용자에게 실수로 재할당할 수 없습니다.

삭제된 사용자#

소스 인스턴스에서 현재 삭제된 사용자가 수행한 기여는 다음의 경우를 제외하고 대상 인스턴스에서 고스트 사용자에게 매핑됩니다:

• 소스 인스턴스에서 삭제된 사용자로부터 기여가 제대로 분리되지 않은 경우.
• Bitbucket Server에서 마이그레이션하는 경우.

플레이스홀더 사용자#

기여 및 멤버십 매핑을 사용하면 대상 인스턴스의 사용자에게 기여 및 멤버십을 즉시 할당하지 않습니다. 대신 임포트된 기여 또는 멤버십이 있는 활성, 비활성 또는 봇 사용자를 위해 플레이스홀더 사용자가 생성됩니다.

기여 및 멤버십 모두 처음에는 이러한 플레이스홀더 사용자에게 할당되며, 임포트 후 대상 인스턴스의 기존 사용자에게 재할당할 수 있습니다.

재할당될 때까지 기여는 플레이스홀더와 연결됩니다. 플레이스홀더 멤버십은 멤버 목록에 표시되지 않습니다.

플레이스홀더 사용자는 라이선스 제한에 포함되지 않습니다.

예외#

다음 시나리오에서는 플레이스홀더 사용자가 생성되지 않습니다:

• 삭제된 사용자의 기여가 있는 Gitea에서 프로젝트를 임포트하는 경우. 이러한 사용자의 기여는 프로젝트를 임포트한 사용자에게 매핑됩니다.
• 플레이스홀더 사용자 제한을 초과한 경우. 새 사용자의 기여는 임포트 사용자에게 매핑됩니다.

플레이스홀더 사용자 속성#

플레이스홀더 사용자는 일반 사용자와 다르며 다음을 할 수 없습니다:

• 로그인.
• 모든 작업 수행. 예를 들어, 파이프라인 실행.
• 이슈 및 머지 리퀘스트의 담당자 또는 리뷰어로 제안에 표시.
• 프로젝트 및 그룹의 멤버가 됨.

소스 인스턴스의 사용자와 연결을 유지하기 위해 플레이스홀더 사용자는 다음을 가집니다:

• 새로운 플레이스홀더 사용자가 필요한지 결정하기 위해 임포트 프로세스에서 사용하는 고유 식별자(source_user_id).
• 소스 호스트명 또는 도메인(source_hostname).
• 기여 재할당에 도움이 되는 소스 사용자의 이름(source_name).
• 기여 재할당 중 그룹 소유자를 위한 소스 사용자의 사용자 이름(source_username).
• 플레이스홀더를 생성한 임포터를 구별하는 임포트 유형(import_type).
• 마이그레이션 추적을 위한 로컬 시간의 소스 사용자 생성 타임스탬프(created_at)(GitLab 17.10에서 도입).

역사적 컨텍스트를 보존하기 위해 플레이스홀더 사용자 이름과 사용자명은 소스 사용자 이름과 사용자명에서 파생됩니다:

• 플레이스홀더 사용자의 이름은 Placeholder <source user name>입니다.
• 플레이스홀더 사용자의 사용자명은 %{source_username}_placeholder_user_%{incremental_number}입니다.

플레이스홀더 사용자 보기#

사전 요구 사항:

• 그룹에 대한 Owner 역할을 가지고 있어야 합니다.

플레이스홀더 사용자는 그룹 또는 프로젝트가 임포트되는 동안 대상 인스턴스에 생성됩니다. 최상위 그룹과 해당 하위 그룹으로의 임포트 중에 생성된 플레이스홀더 사용자를 보려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Manage > Members를 선택합니다.
3. Placeholders 탭을 선택합니다.

플레이스홀더 사용자 필터링#

히스토리

• GitLab 17.11에서 도입되었습니다.

사전 요구 사항:

• 인스턴스에 대한 관리자 접근 권한을 가지고 있어야 합니다.

플레이스홀더 사용자는 그룹 또는 프로젝트가 임포트되는 동안 대상 인스턴스에 생성됩니다. 전체 인스턴스에 대한 임포트 중에 생성된 플레이스홀더 사용자를 필터링하려면:

1. 오른쪽 상단 모서리에서 Admin을 선택합니다.
2. Overview > Users를 선택합니다.
3. 검색 상자에서 type으로 사용자를 필터링합니다.

플레이스홀더 사용자 생성#

플레이스홀더 사용자는 임포트 소스별 및 최상위 그룹별로 생성됩니다:

• 동일한 프로젝트를 대상 인스턴스의 동일한 최상위 그룹에 두 번 임포트하면 두 번째 임포트는 첫 번째 임포트와 동일한 플레이스홀더 사용자를 사용합니다.
• 동일한 프로젝트를 두 번 임포트하지만 대상 인스턴스의 다른 최상위 그룹에 임포트하면 두 번째 임포트는 해당 최상위 그룹 아래에 새로운 플레이스홀더 사용자를 생성합니다.

사용자가 재할당을 수락하면, 동일한 소스 인스턴스에서 대상 인스턴스의 동일한 최상위 그룹 또는 하위 그룹으로의 이후 임포트에서 플레이스홀더 사용자가 생성되지 않습니다. 대신 기여는 자동으로 사용자에게 매핑됩니다.

플레이스홀더 사용자 삭제#

히스토리

• GitLab 18.0에서 도입되었습니다.

플레이스홀더 사용자가 포함된 최상위 그룹을 삭제하면 이러한 사용자가 자동으로 삭제 예약됩니다. 이 프로세스는 완료하는 데 시간이 걸릴 수 있습니다. 그러나 플레이스홀더 사용자가 다른 프로젝트나 그룹과도 연결된 경우 시스템에 남아 있습니다.

플레이스홀더 사용자 제한#

GitLab.com으로 임포트하는 경우 플레이스홀더 사용자는 대상 인스턴스의 최상위 그룹당 제한이 있습니다. 제한은 플랜과 시트 수에 따라 다릅니다. 플레이스홀더 사용자는 라이선스 제한에 포함되지 않습니다.

GitLab Self-Managed 및 GitLab Dedicated의 경우 기본적으로 플레이스홀더 제한이 적용되지 않습니다. GitLab 관리자는 인스턴스에서 플레이스홀더 제한을 설정할 수 있습니다.

현재 플레이스홀더 사용자 사용량과 제한을 보려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Settings > Usage quotas를 선택합니다.
3. Import 탭을 선택합니다.

사전에 필요한 플레이스홀더 사용자 수를 결정할 수 없습니다.

플레이스홀더 사용자 제한에 도달하면 모든 기여가 Import User라는 단일 비기능 사용자에게 할당됩니다. Import User에 할당된 기여는 중복 제거될 수 있으며, 임포트 중에 일부 기여가 생성되지 않을 수 있습니다. 예를 들어, 머지 리퀘스트 승인자의 여러 승인이 Import User에 할당되면 첫 번째 승인만 생성되고 나머지는 무시됩니다. 중복 제거될 수 있는 기여는:

• 승인 규칙
• 이모지 반응
• 이슈 담당자
• 멤버십
• 머지 리퀘스트 승인, 담당자, 리뷰어
• 푸시, 머지 리퀘스트, 배포 접근 레벨

모든 변경 사항은 시스템 노트를 생성하며, 플레이스홀더 사용자 제한의 영향을 받지 않습니다.

기여 및 멤버십 재할당#

최상위 그룹에 대한 Owner 역할을 가진 사용자는 플레이스홀더 사용자의 기여 및 멤버십을 기존 활성 비봇 사용자에게 재할당할 수 있습니다. 대상 인스턴스에서 최상위 그룹에 대한 Owner 역할을 가진 사용자는 다음을 수행할 수 있습니다:

• UI에서 또는 CSV 파일을 통해 사용자에게 기여 및 멤버십 재할당 검토를 요청합니다. 다수의 플레이스홀더 사용자가 있는 경우 CSV 파일을 사용해야 합니다. 두 경우 모두 사용자는 재할당을 수락하거나 거부하라는 이메일 요청을 받습니다. 재할당은 선택된 사용자가 재할당 요청을 수락한 후에만 시작됩니다.
• 기여 및 멤버십을 재할당하지 않고 플레이스홀더 사용자에게 할당된 상태로 유지하도록 선택합니다.

GitLab Self-Managed 및 GitLab Dedicated에서 관리자는 확인 없이 활성 및 비활성 비봇 사용자에게 즉시 기여 및 멤버십을 재할당할 수 있습니다. 자세한 내용은 관리자가 플레이스홀더 사용자를 재할당할 때 확인 건너뛰기를 참조하세요. 관리자에게 기여 및 멤버십을 재할당하려면 관리자에게 기여 매핑 허용을 참조하세요.

플레이스홀더 사용자 재할당 시 확인 우회#

히스토리

• GitLab 18.1에서 group_owner_placeholder_confirmation_bypass라는 기능 플래그와 함께 GitLab.com에 도입되었습니다. 기본값으로 비활성화됩니다.
• GitLab 18.4에서 GitLab.com에서 활성화되었습니다.
• GitLab 18.7에서 GitLab.com에서 일반 공개되었습니다. 기능 플래그 group_owner_placeholder_confirmation_bypass가 제거되었습니다.

사전 요구 사항:

• 그룹에 대한 Owner 역할을 가지고 있어야 합니다.

플레이스홀더를 재할당할 때 엔터프라이즈 사용자에 대한 확인을 우회하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Settings > General을 선택합니다.
3. Permissions and group features를 확장합니다.
4. Placeholder user confirmation 아래에서 엔터프라이즈 사용자에게 사용자 확인 없이 플레이스홀더 재할당 체크박스를 선택합니다.
5. 사용자 확인 복원 시점에서 사용자 확인 우회의 종료 날짜를 선택합니다. 기본값은 하루입니다.
6. Save changes를 선택합니다.

여러 플레이스홀더 사용자의 기여 재할당#

단일 플레이스홀더 사용자에게 처음 할당된 모든 기여를 대상 인스턴스의 단일 활성 일반 사용자, 서비스 계정, 프로젝트 봇, 그룹 봇에게 재할당할 수 있습니다. 단일 플레이스홀더 사용자에게 할당된 기여를 여러 사용자 간에 분할할 수 없습니다.

다음의 경우 여러 플레이스홀더 사용자의 기여를 대상 인스턴스의 동일한 사용자에게 재할당할 수 있습니다:

• 다른 소스 인스턴스에서 온 플레이스홀더 사용자인 경우
• 동일한 소스 인스턴스에서 대상 인스턴스의 다른 최상위 그룹으로 임포트된 플레이스홀더 사용자인 경우

할당된 사용자가 재할당 요청을 수락하기 전에 비활성화되면, 보류 중인 재할당은 수락할 때까지 사용자와 연결된 상태를 유지합니다.

재할당 요청을 받은 사용자는 다음을 선택할 수 있습니다:

• 요청을 수락합니다. 이전에 플레이스홀더 사용자에게 귀속된 모든 기여와 멤버십이 수락한 사용자에게 재귀속됩니다. 이 프로세스는 기여 수에 따라 몇 분이 걸릴 수 있습니다.
• 요청을 거부하거나 스팸으로 신고합니다. 이 옵션은 재할당 요청 이메일에서 사용할 수 있습니다.

서비스 계정, 프로젝트 봇, 그룹 봇에 기여를 재할당하면 재할당 요청이 자동으로 승인됩니다.

동일한 최상위 그룹으로의 이후 임포트에서, 동일한 소스 사용자에 속한 기여와 멤버십은 해당 소스 사용자에 대한 재할당을 이전에 수락한 사용자에게 자동으로 매핑됩니다.

GitLab Self-Managed 및 GitLab Dedicated에서 관리자는 확인 없이 활성 및 비활성 비봇 사용자에게 즉시 기여 및 멤버십을 재할당할 수 있습니다. 자세한 내용은 관리자가 플레이스홀더 사용자를 재할당할 때 확인 건너뛰기를 참조하세요. 관리자에게 기여 및 멤버십을 재할당하려면 관리자에게 기여 매핑 허용을 참조하세요.

재할당 완료#

다음을 수행하기 전에 재할당 프로세스를 완전히 완료해야 합니다:

• 동일한 GitLab 인스턴스 내에서 임포트된 그룹 이동.
• 임포트된 프로젝트를 다른 그룹으로 이동.
• 임포트된 이슈 복제.
• 임포트된 이슈를 에픽으로 승격.

프로세스가 완료되지 않으면 플레이스홀더 사용자에게 여전히 할당된 기여를 실제 사용자에게 재할당할 수 없으며 플레이스홀더 사용자와 연결된 상태를 유지합니다.

보안 고려 사항#

기여 및 멤버십 재할당은 취소할 수 없으므로 시작하기 전에 모든 것을 신중하게 확인하세요.

잘못된 사용자에게 기여 및 멤버십을 재할당하면 해당 사용자가 그룹의 멤버가 되기 때문에 보안 위협이 될 수 있습니다. 따라서 볼 수 없어야 하는 정보를 볼 수 있게 됩니다.

관리자 접근 권한이 있는 사용자에게 기여를 재할당하는 것은 기본적으로 비활성화되어 있지만 활성화할 수 있습니다.

멤버십 보안 고려 사항#

GitLab 권한 모델로 인해 그룹 또는 프로젝트가 기존 상위 그룹으로 임포트되면 상위 그룹의 멤버는 임포트된 그룹 또는 프로젝트의 상속된 멤버십이 부여됩니다.

기여 및 멤버십 재할당을 위해 임포트된 그룹 또는 프로젝트의 기존 상속된 멤버십이 이미 있는 사용자를 선택하면 해당 사용자에 대한 멤버십 재할당 방식에 영향을 줄 수 있습니다.

GitLab은 하위 프로젝트 또는 그룹의 멤버십이 상속된 멤버십보다 낮은 역할을 가지는 것을 허용하지 않습니다. 할당된 사용자의 임포트된 멤버십이 기존 상속된 멤버십보다 낮은 역할인 경우 임포트된 멤버십은 사용자에게 재할당되지 않습니다.

이로 인해 임포트된 그룹 또는 프로젝트에 대한 멤버십이 소스보다 높아집니다.

UI에서 재할당 요청#

사전 요구 사항:

• 그룹에 대한 Owner 역할을 가지고 있어야 합니다.

최상위 그룹에서 기여 및 멤버십을 재할당할 수 있습니다. 기여 및 멤버십 재할당을 요청하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Manage > Members를 선택합니다.
3. Placeholders 탭을 선택합니다.
4. Awaiting reassignment 하위 탭으로 이동하면 플레이스홀더가 테이블에 나열됩니다.
5. 각 플레이스홀더에 대해 Placeholder user 및 Source 테이블 열의 정보를 검토합니다.
6. Reassign placeholder to 열에서 드롭다운 목록에서 사용자를 선택합니다.
7. Reassign을 선택합니다.

단일 플레이스홀더 사용자의 기여만 대상 인스턴스의 활성 비봇 사용자에게 재할당할 수 있습니다.

사용자가 재할당을 수락하기 전에 요청을 취소할 수 있습니다.

GitLab Self-Managed 및 GitLab Dedicated에서 관리자는 확인 없이 활성 및 비활성 비봇 사용자에게 즉시 기여 및 멤버십을 재할당할 수 있습니다. 자세한 내용은 관리자가 플레이스홀더 사용자를 재할당할 때 확인 건너뛰기를 참조하세요. 관리자에게 기여 및 멤버십을 재할당하려면 관리자에게 기여 매핑 허용을 참조하세요.

CSV 파일을 사용하여 재할당 요청#

히스토리

• GitLab 17.10에서 importer_user_mapping_reassignment_csv라는 플래그와 함께 도입되었습니다. 기본값으로 활성화됩니다.
• GitLab 18.0에서 일반 공개되었습니다. 기능 플래그 importer_user_mapping_reassignment_csv가 제거되었습니다.

사전 요구 사항:

• 그룹에 대한 Owner 역할을 가지고 있어야 합니다.

다수의 플레이스홀더 사용자가 있는 경우 CSV 파일을 사용하여 기여 및 멤버십을 재할당하는 것이 좋습니다. 다음 정보가 미리 채워진 CSV 템플릿을 다운로드할 수 있습니다. 예를 들어:

Source host, Import type, Source user identifier는 업데이트하지 마세요. 이 정보는 완성된 CSV 파일을 업로드한 후 해당 데이터베이스 레코드를 찾는 데 사용됩니다. Source user name 및 Source username은 소스 사용자를 식별하며 CSV 파일을 업로드한 후에는 사용되지 않습니다.

CSV 파일의 모든 행을 업데이트할 필요는 없습니다. GitLab username 또는 GitLab public email이 있는 행만 처리됩니다. 다른 모든 행은 건너뜁니다.

CSV 파일을 사용하여 기여 및 멤버십 재할당을 요청하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. Manage > Members를 선택합니다.
3. Placeholders 탭을 선택합니다.
4. Reassign with CSV를 선택합니다.
5. 미리 채워진 CSV 템플릿을 다운로드합니다.
6. GitLab username 또는 GitLab public email에 대상 인스턴스의 GitLab 사용자의 사용자명 또는 공개 이메일 주소를 입력합니다. 인스턴스 관리자는 확인된 이메일 주소가 있는 사용자에게 재할당할 수 있습니다.
7. 완성된 CSV 파일을 업로드합니다.
8. Reassign을 선택합니다.

대상 인스턴스의 각 활성 비봇 사용자에게 단일 플레이스홀더 사용자의 기여만 할당할 수 있습니다. 사용자는 재할당된 기여를 검토하고 수락하라는 이메일을 받습니다. 사용자가 검토하기 전에 재할당 요청을 취소할 수 있습니다.

GitLab Self-Managed 및 GitLab Dedicated에서 관리자는 확인 없이 활성 및 비활성 비봇 사용자에게 즉시 기여 및 멤버십을 재할당할 수 있습니다. 자세한 내용은 관리자가 플레이스홀더 사용자를 재할당할 때 확인 건너뛰기를 참조하세요. 관리자에게 기여 및 멤버십을 재할당하려면 관리자에게 기여 매핑 허용을 참조하세요.

기여를 재할당한 후 GitLab은 다음 수를 포함하는 이메일을 보냅니다:

• 성공적으로 처리된 행
• 성공적으로 처리되지 않은 행
• 건너뛴 행

성공적으로 처리되지 않은 행이 있으면 이메일에 더 자세한 결과가 포함된 CSV 파일이 첨부됩니다.

UI를 사용하지 않고 대량으로 플레이스홀더 사용자를 재할당하려면 그룹 플레이스홀더 재할당 API를 참조하세요.

플레이스홀더로 유지#

히스토리

• GitLab 18.5에서 작업을 취소할 수 있도록 변경되었습니다.

대상 인스턴스의 사용자에게 기여 및 멤버십을 재할당하지 않을 수 있습니다. 예를 들어, 소스 인스턴스에서 기여했지만 대상 인스턴스의 사용자로 존재하지 않는 이전 직원이 있을 수 있습니다.

이러한 경우 플레이스홀더 사용자에게 할당된 기여를 유지할 수 있습니다. 플레이스홀더 사용자는 프로젝트 또는 그룹의 멤버가 될 수 없기 때문에 멤버십 정보를 유지하지 않습니다.

플레이스홀더 사용자의 이름과 사용자명이 소스 사용자의 이름과 사용자명을 닮았기 때문에 많은 역사적 컨텍스트를 유지할 수 있습니다.

한 번에 하나씩 또는 대량으로 플레이스홀더 사용자에게 기여를 할당된 상태로 유지할 수 있습니다. 대량으로 기여를 재할당할 때 전체 네임스페이스와 다음 재할당 상태를 가진 사용자가 영향을 받습니다:

• Not started
• Rejected

플레이스홀더 사용자를 한 번에 하나씩 유지하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Manage > Members를 선택합니다.
3. Placeholders 탭을 선택합니다.
4. Awaiting reassignment 하위 탭으로 이동하면 플레이스홀더가 테이블에 나열됩니다.
5. Placeholder user 및 Source 열을 검토하여 유지하려는 플레이스홀더 사용자를 찾습니다.
6. Reassign placeholder to 열에서 Do not reassign을 선택합니다.
7. Confirm을 선택합니다.

플레이스홀더 사용자를 대량으로 유지하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Manage > Members를 선택합니다.
3. Placeholders 탭을 선택합니다.
4. 목록 위에서 세로 줄임표(⋮) > Keep all as placeholders를 선택합니다.
5. 확인 대화 상자에서 Confirm을 선택합니다.

작업을 취소하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Manage > Members를 선택합니다.
3. Placeholders 탭을 선택합니다.
4. Reassigned 하위 탭으로 이동하면 플레이스홀더가 테이블에 나열됩니다.
5. 해당 행에서 Undo를 선택합니다.

재할당 요청 취소#

사용자가 재할당 요청을 수락하기 전에 요청을 취소할 수 있습니다:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Manage > Members를 선택합니다.
3. Placeholders 탭을 선택합니다.
4. Awaiting reassignment 하위 탭으로 이동하면 플레이스홀더가 테이블에 나열됩니다.
5. 해당 행에서 Cancel을 선택합니다.

보류 중인 재할당 요청에 대해 사용자에게 다시 알림#

사용자가 재할당 요청에 따르지 않는 경우 다른 이메일을 보내 다시 알릴 수 있습니다:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Manage > Members를 선택합니다.
3. Placeholders 탭을 선택합니다.
4. Awaiting reassignment 하위 탭으로 이동하면 플레이스홀더가 테이블에 나열됩니다.
5. 해당 행에서 Notify를 선택합니다.

재할당 상태 보기 및 필터링#

모든 플레이스홀더 사용자의 재할당 상태를 보려면:

1. 상단 바에서 검색 또는 이동을 선택하고 그룹을 찾습니다. 이 그룹은 최상위 레벨이어야 합니다.
2. Manage > Members를 선택합니다.
3. Placeholders 탭을 선택합니다.
4. Awaiting reassignment 하위 탭으로 이동하면 플레이스홀더가 테이블에 나열됩니다.
5. Reassignment status 열에서 각 플레이스홀더 사용자의 상태를 확인합니다.

Awaiting reassignment 탭에서 가능한 상태:

• Not started - 재할당이 시작되지 않았습니다.
• Pending approval - 재할당이 사용자 승인을 기다리고 있습니다.
• Reassigning - 재할당이 진행 중입니다.
• Rejected - 사용자가 재할당을 거부했습니다.
• Failed - 재할당이 실패했습니다.

Reassigned 탭에서 가능한 상태:

• Success - 재할당이 성공했습니다.
• Kept as placeholder - 플레이스홀더 사용자가 영구적으로 지정되었습니다.

기본적으로 테이블은 플레이스홀더 사용자 이름으로 알파벳순으로 정렬됩니다. 재할당 상태로도 테이블을 정렬할 수 있습니다.

기여 재할당 확인#

관리자가 플레이스홀더 사용자를 재할당할 때 확인 건너뛰기가 활성화된 경우:

• 관리자는 사용자 확인 없이 즉시 기여를 재할당할 수 있습니다.
• 관리자는 활성 및 비활성 비봇 사용자에게 기여를 재할당할 수 있습니다.
• 기여가 재할당되었다는 알림 이메일을 받습니다.

이 설정이 활성화되지 않은 경우 재할당을 수락하거나 거부할 수 있습니다.

기여 재할당 수락#

임포트 프로세스가 발생했으며 자신에게 기여 재할당을 확인하도록 요청하는 이메일을 받을 수 있습니다.

이 임포트 프로세스에 대해 사전에 알고 있었더라도 재할당 세부 사항을 매우 신중하게 검토해야 합니다. 이메일에 나열된 세부 사항은:

• Imported from - 임포트된 콘텐츠가 원본으로 있는 플랫폼. 예를 들어, 다른 GitLab 인스턴스, GitHub, Bitbucket.
• Original user - 소스 플랫폼의 사용자 이름과 사용자명. 해당 플랫폼에서의 자신의 이름과 사용자명일 수 있습니다.
• Imported to - 새 플랫폼의 이름으로 GitLab 인스턴스만 될 수 있습니다.
• Reassigned to - GitLab 인스턴스에서 자신의 전체 이름과 사용자명.
• Reassigned by - 임포트를 수행한 동료 또는 관리자의 전체 이름과 사용자명.

기여 재할당 거부#

자신에게 기여 재할당을 확인하도록 요청하는 이메일을 받았는데 이 정보를 인식하지 못하거나 오류를 발견한 경우:

1. 전혀 진행하지 않거나 기여 재할당을 거부합니다.
2. 신뢰할 수 있는 동료 또는 관리자에게 이야기합니다.

보안 고려 사항#

재할당 요청의 재할당 세부 사항을 매우 신중하게 검토해야 합니다. 신뢰할 수 있는 동료 또는 관리자로부터 이미 이 프로세스에 대해 알지 못했다면 더욱 주의해야 합니다.

의심이 가는 재할당을 수락하는 것보다:

1. 이메일에 응하지 않습니다.
2. 신뢰할 수 있는 동료 또는 관리자에게 이야기합니다.

알고 신뢰하는 사용자의 재할당만 수락합니다. 기여 재할당은 영구적이며 취소할 수 없습니다. 재할당을 수락하면 기여가 잘못 귀속될 수 있습니다.

기여 재할당 프로세스는 GitLab에서 Approve reassignment를 선택하여 재할당 요청을 수락한 후에만 시작됩니다. 이메일의 링크를 선택한다고 프로세스가 시작되지 않습니다.

대체 매핑 방법#

마이그레이션 후 매핑의 대안은 마이그레이션 중에 매핑하는 방법입니다. 이 방법은 권장되지 않으며 발견된 문제가 수정될 가능성이 낮습니다.

대체 매핑 방법:

• 기능 플래그 비활성화를 포함하여 마이그레이션 전에 일부 준비가 필요합니다.
• 다음에서의 마이그레이션에 사용할 수 있습니다:
  • GitHub.
  • Bitbucket Server.
  • Gitea(GitLab 18.5 이하).
• GitLab Self-Managed 및 GitLab Dedicated로의 마이그레이션에 사용할 수 있습니다.

자세한 내용은 각 임포터에 대한 대체 매핑 방법 문서를 참조하세요.