그룹 및 프로젝트 가져오기 및 이주

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

기존 프로젝트를 GitLab로 가져오거나 GitLab 그룹 및 프로젝트를 다른 위치로 복사하려면 다음을 수행할 수 있습니다:

  • 직접 전송을 사용하여 GitLab 그룹 및 프로젝트를 마이그레이션합니다.
  • 지원되는 가져오기 소스에서 가져옵니다.
  • 다른 가져오기 소스에서 가져옵니다.

직접 전송을 사용하여 GitLab에서 GitLab로 마이그레이션

GitLab 인스턴스 간이나 동일한 GitLab 인스턴스에서 GitLab 그룹 및 프로젝트를 복사하는 가장 좋은 방법은 직접 전송을 사용하는 것입니다.

다른 옵션으로는 GitLab 그룹을 그룹 전송하는 것이 있습니다.

또한 지원되는 가져오기 소스인 GitLab 파일 내보내기를 사용하여 GitLab 프로젝트를 복사할 수 있습니다.

지원되는 가져오기 소스

  • GitLab 자체 관리 설치에서 모든 가져오기기본적으로 비활성화됩니다. 이 변경 사항은 GitLab 16.0에서 소개되었습니다.

기본적으로 사용 가능한 가져오기 소스는 사용 중인 GitLab에 따라 달라집니다:

  • GitLab.com: 모든 사용 가능한 가져오기 소스가 기본적으로 활성화됩니다.
  • 자체 관리형 GitLab: 가져오기 소스가 기본적으로 비활성화되어 있으며 활성화해야 합니다.

GitLab은 이러한 지원되는 가져오기 소스로부터 프로젝트를 가져올 수 있습니다.

가져오기 소스 설명
Bitbucket Cloud Bitbucket.org을 OmniAuth 프로바이더로 사용하여 Bitbucket 리포지토리를 가져옵니다.
Bitbucket Server Bitbucket Server(Stash로도 알려짐)에서 리포지토리를 가져옵니다.
FogBugz FogBugz 프로젝트를 가져옵니다.
Gitea Gitea 프로젝트를 가져옵니다.
GitHub GitHub.com 또는 GitHub Enterprise에서 가져옵니다.
GitLab export GitLab 내보내기 파일을 사용하여 한 번에 프로젝트를 마이그레이션합니다.
Manifest file 매니페스트 파일을 업로드합니다.
Repository by URL Git 저장소 URL을 제공하여 새 프로젝트를 생성합니다.

사용되지 않는 가져오기 소스 비활성화

신뢰할 수 있는 소스에서만 프로젝트를 가져옵니다. 신뢰할 수 없는 소스에서 프로젝트를 가져오는 경우, 공격자가 민감한 데이터를 도용할 수 있습니다. 예를 들어, 악성 .gitlab-ci.yml 파일을 포함한 가져온 프로젝트를 통해 공격자가 그룹 CI/CD 변수를 유출할 수 있습니다.

자체 관리형 GitLab 관리자는 필요하지 않은 가져오기 소스를 비활성화하여 공격 표면을 줄일 수 있습니다:

  1. 왼쪽 사이드바에서 아래쪽에서 관리자를 선택합니다.
  2. 설정 > 일반을 선택합니다.
  3. 가져오기 및 내보내기 설정을 확장합니다.
  4. 가져오기 소스로 스크롤합니다.
  5. 필요하지 않은 가져오기기체를 위한 확인란을 지웁니다.

기타 가져오기 소스

다음 다른 가져오기 소스에서 가져오기에 대한 정보를 읽어볼 수도 있습니다:

Subversion에서 리포지토리 가져오기

GitLab은 Subversion 리포지토리를 자동으로 Git으로 마이그레이션할 수 없습니다. Subversion 리포지토리를 Git으로 변환하는 것은 어려울 수 있지만, git svn은 매우 작고 기본적인 저장소에 대해 포함됩니다. reposurgeon은 더 크고 복잡한 저장소에 대해 포함됩니다.

사용자 기여 및 멤버십 매핑

Status: Experiment

플래그: 이 기능의 사용 가능성은 피쳐 플래그에 의해 제어됩니다. 자세한 정보는 히스토리를 참조하십시오. 이 기능은 내부 테스트용으로만 사용 가능하며, 제품용으로 준비되지 않았습니다.

사용자 기여 및 멤버십 매핑을 사용하면 가져오기가 완료된 후 대상 인스턴스의 사용자에게 가져온 기여와 멤버십을 지정할 수 있습니다. 이전 방법과 달리 사용자 기여 및 멤버십 매핑을 위한 준비가 필요하지 않습니다.

이 프로세스는 이메일 주소에 의존하지 않으므로 소스와 대상 인스턴스에서 이메일이 다른 사용자의 기여를 지정할 수 있습니다.

참고: 이 사용자 기여 및 멤버십 방법은 직접 전송을 사용한 마이그레이션에서만 지원됩니다. 직접 전송 마이그레이션을 위한 사용자 기여 및 멤버십 매핑의 다른 방법에 대한 정보는 다음을 참조하십시오. 사용자 기여 및 멤버십 매핑.

매핑이 지정된 대상 인스턴스의 각 사용자는 다음을 수행할 수 있습니다:

  • 명시적으로 수락하여 가져온 기여가 그들에게 지정되기 전에 수락하기.
  • 매핑을 거부하기.

이 기능은 실험입니다. 버그가 발견되면 epic 12378에서 이슈를 엽니다.

요구 사항

  • 충분한 사용자를 생성할 수 있어야 합니다. 사용자 제한에 따름.
  • GitLab.com으로 가져오기하는 경우 가져오기 전에 유료 네임스페이스를 설정해야 합니다.

사용자 제한

대상 인스턴스에 사용자의 기여와 멤버십이 즉시 지정되는 대신 가져온 사용자의 기여 및 멤버십에는 임시 사용자가 생성됩니다.

기여와 멤버십은 먼저 이러한 임시 사용자에 지정되며 가져오기 후에 대상 인스턴스의 기존 사용자에게 다시 지정할 수 있습니다.

다시 지정되었을 때에만 기여가 임시 사용자와 연결됩니다. 임시 멤버십의 경우 멤버 목록에 표시되지 않습니다.

사용자 속성 자리 표시자

일반 사용자와는 다른 특징이 있는 자리 표시자 사용자는 다음을 수행할 수 없습니다:

  • 로그인.
  • 파이프라인 실행과 같은 모든 작업 수행.
  • 이슈 및 병합 요청의 담당자나 리뷰어로 제안될 수 없습니다.
  • 프로젝트 및 그룹의 구성원이 될 수 없습니다.

소스 인스턴스의 사용자와의 연결을 유지하기 위해 자리 표시자 사용자는 다음을 갖추고 있습니다:

  • 수입 프로세스가 새로운 자리 표시자 사용자가 필요한지 확인하는 데 사용하는 고유 식별자(source_user_id).
  • 소스 호스트명이나 도메인(source_hostname).
  • 기여 재할당을 돕기 위해 소스 사용자의 이름(source_name).
  • 그룹 소유자가 기여를 재할당하는 데 도움이 되는 소스 사용자의 사용자 이름(source_username).
  • 자리 표시자가 만들어진 가져오기 유형(import_type)을 구분하는 데 사용됩니다.

역사적 맥락을 보존하기 위해 자리 표시자 사용자 이름과 사용자 이름은 소스 사용자 이름과 사용자 이름에서 파생됩니다:

  • 자리 표시자 사용자 이름은 Placeholder <소스 사용자 이름>입니다.
  • 자리 표시자 사용자의 사용자 이름은 %{source_username}_placeholder_user_%{incremental_number}입니다.

자리 표시자 사용자 보기

전제 조건:

  • 그룹에 대한 소유자 역할이 있어야 합니다.

자리 표시자 사용자는 그룹 또는 프로젝트를 가져올 때 대상 인스턴스에 만들어집니다. 상위 그룹과 해당 하위 그룹으로 가져오기 중에 만들어진 자리 표시자 사용자를 보려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 관리 > 구성원을 선택합니다.
  3. 자리 표시자 탭을 선택합니다.

자리 표시자 사용자 제한

자리 표시자 사용자는 가능한 가져오기 원본 및 상위 그룹당 만들어집니다:

  • 동일한 프로젝트를 대상 인스턴스의 동일한 상위 그룹으로 두 번 가져오면 두 번째 가져오기는 첫 번째 가져오기와 동일한 자리 표시자 사용자를 사용합니다.
  • 동일한 프로젝트를 두 번 가져오지만 대상 인스턴스의 다른 상위 그룹으로 가져오면 두 번째 가져오기는 해당 상위 그룹에 새로운 자리 표시자 사용자를 만듭니다.

GitLab.com으로 가져오기를 할 경우 자리 표시자 사용자는 대상 인스턴스의 상위 그룹당 제한됩니다. 제한은 요금제 및 좌석 수에 따라 다릅니다. 자리 표시자 사용자는 라이선스 제한에 포함되지 않습니다.

GitLab.com 요금제 좌석 수 상위 그룹당 자리 표시자 사용자 제한
무료 및 임시 사용자 임의의 양 200
프리미엄 < 100 500
프리미엄 101-500 2000
프리미엄 501 - 1000 4000
프리미엄 > 1000 6000
얼티밋 및 오픈 소스 < 100 1000
얼티밋 및 오픈 소스 101-500 4000
얼티밋 및 오픈 소스 501 - 1000 6000
얼티밋 및 오픈 소스 > 1000 8000

이전 브론즈, 실버 또는 골드 요금제의 고객들은 대응되는 무료, 프리미엄 또는 얼티밋 제한을 받습니다. Ultimate 평가판 유료 고객(얼티밋 평가판 유료 고객)의 경우 프리미엄 제한이 적용됩니다.

이러한 제한이 가져오기에 충분하지 않은 경우 GitLab 지원팀에 문의하십시오.

위 제한은 GitLab.com용입니다. 기본적으로 self-managed GitLab에는 자리 표시자 제한이 없습니다. 자체 관리 인스턴스 관리자는 자리 표시자 제한을 설정할 수 있습니다.

기여 및 구성원 재할당

기여 및 구성원을 자리 표시자 사용자로부터 기존 활성(봇 제외) 사용자로 재할당은 대상 인스턴스에서 발생합니다. 대상 인스턴스에서 다음을 수행할 수 있습니다:

최초로 하나의 자리 표시자 사용자에 할당된 모든 기여는 대상 인스턴스에서 하나의 활성 정규 사용자에게만 재할당될 수 있습니다. 단일 자리 표시자 사용자에 할당된 기여는 여러 활성 정규 사용자 사이에 나눠지지 않습니다.

소스 인스턴스의 봇 사용자 기여와 구성원을 대상 인스턴스의 봇 사용자에게 재할당할 수 없습니다. 소스 봇 사용자의 기여를 자리 표시자 사용자에 할당하도록 선택할 수 있습니다.

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

  • 요청을 수락. 이는 이전에 자리 표시자 사용자에게 귀속된 모든 기여 및 구성원이 수락한 사용자에게 다시 귀속됩니다. 이 절차는 기여의 수에 따라 몇 분이 걸릴 수 있습니다.
  • 요청을 거부하거나 스팸 신고를 할 수 있습니다. 이 옵션은 재할당 요청 이메일에서 이용할 수 있습니다.

이후의 가져오기에서는 동일한 소스 사용자에 속한 기여와 구성원은 해당 소스 사용자에게 이전에 재할당을 수락한 사용자에게 자동으로 매핑됩니다.

재할당 절차는 반드시 완전히 완료되어야 합니다.

절차가 완료되지 않으면 자리 표시자 사용자에게 할당된 기여는 실 사용자에게 재할당되지 않으며 계속하여 자리 표시자 사용자와 관련이 유지됩니다.

보안 고려 사항

기여 및 구성원 재할당이 완료되면 취소되지 않으므로 시작하기 전에 모두 확인하십시오.

기여 및 구성원을 잘못된 사용자에게 재할당하면 보안 위협이 발생할 수 있습니다. 해당 사용자가 그룹의 구성원이 되므로 볼 수 없어야 할 정보를 볼 수 있습니다.

관리자 액세스를 갖고 있는 사용자에게 기여를 재할당하는 것은 기본적으로 비활성화되어 있지만 활성화할 수 있습니다.

구성원 보안 고려 사항

GitLab 권한 모델 때문에 기존 상위 그룹으로 그룹 또는 프로젝트를 가져오면 상위 그룹의 구성원들이 가져온 그룹 또는 프로젝트에 대해 상속된 구성원 자격을 받습니다.

기여와 구성원을 재할당할 사용자를 선택하는 경우 이미 가져온 그룹 또는 프로젝트에 대한 상속된 구성원 자격을 가지고 있는 사용자를 선택하는 것은 해당 사용자에게 재할당된 구성원에 어떤 영향을 미칠지에 영향을 줄 수 있습니다.

GitLab에서는 자식 프로젝트나 그룹의 구성원 자격이 상속된 멤버십보다 낮은 역할을 가질 수 없습니다. 할당된 사용자에 대한 가져온 멤버십이 해당 사용자의 기존 상속 멤버십보다 낮은 역할을 가지고 있으면 가져온 멤버십은 재할당되지 않습니다.

이는 가져온 그룹 또는 프로젝트의 멤버십이 가져온 소스보다 더 높게 유지되도록 합니다.

UI에서 재할당 요청

전제 조건:

  • 그룹의 소유자 역할이 있어야 합니다.

사용자에게 기여 및 멤버십 재할당을 요청하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 관리 > 멤버를 선택합니다.
  3. 플레이스홀더 탭을 선택합니다.
  4. Placeholder가 표시된 재할당 대기 서브탭으로 이동합니다.
  5. 각 placeholder에 대해 테이블 열 Placeholder 사용자 및 소스의 정보를 검토합니다.
  6. 플레이스홀더를 다시할당 대상 열에서 드롭다운 목록에서 사용자를 선택합니다.
  7. 다시할당을 선택합니다.

한 placeholder 사용자의 기여는 대상 인스턴스의 활성 비트가 아닌 사용자에게 재할당될 수 있습니다.

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

placeholder 유지

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

이러한 경우, placeholder 사용자가 할당된 기여를 유지할 수 있습니다. Placeholder 사용자는 멤버쉽 정보를 유지하지 않으며, 이는 프로젝트나 그룹의 멤버가 될 수 없음을 의미합니다.

placeholder 사용자의 이름 및 사용자 이름이 소스 사용자의 이름 및 사용자 이름과 유사하기 때문에 많은 이력적인 컨텍스트를 유지할 수 있습니다.

placeholder 사용자를 계속 placeholder로 유지하면 나중에 실제 사용자에게 기여를 재할당할 수 없게 됩니다. 남아 있는 placeholder 사용자를 placeholder로 유지하기 전에 필요한 모든 재할당이 완료되었는지 확인하세요.

한 번에 하나씩 placeholder 사용자를 유지하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 관리 > 멤버를 선택합니다.
  3. 플레이스홀더 탭을 선택합니다.
  4. Placeholder가 표시된 재할당 대기 서브탭으로 이동합니다.
  5. 유지하려는 placeholder 사용자를 Placeholder 사용자 및 소스 열을 검토하여 찾습니다.
  6. 플레이스홀더를 다시할당 대상 열에서 다시할당하지 않음을 선택합니다.
  7. 확인을 선택합니다.

다음의 대용량 placeholder 사용자를 유지하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 관리 > 멤버를 선택합니다.
  3. 플레이스홀더 탭을 선택합니다.
  4. 다시할당하는 CSV와 함께 재할당 옆에있는 더 많은 옵션 아이콘을 선택합니다.
  5. 모두 placeholder로 유지 옵션을 선택합니다.
  6. 확인 대화 상자에서 확인을 선택합니다.

재할당 요청 취소

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 관리 > 멤버를 선택합니다.
  3. 플레이스홀더 탭을 선택합니다.
  4. Placeholder가 표시된 재할당 대기 서브탭으로 이동합니다.
  5. 올바른 행에서 취소를 선택합니다.

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

사용자가 재할당 요청에 대해 조치를 취하지 않는 경우 추가 이메일을 보내어 다시 프롬프트할 수 있습니다:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 관리 > 멤버를 선택합니다.
  3. 플레이스홀더 탭을 선택합니다.
  4. Placeholder가 표시된 재할당 대기 서브탭으로 이동합니다.
  5. 올바른 행에서 알림을 선택합니다.

재할당 상태보기 및 필터링 및 정렬

아직 완료되지 않은 재할당 프로세스에 대한 모든 placeholder 사용자의 상태를 검토할 수 있습니다:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. 관리 > 멤버를 선택합니다.
  3. 플레이스홀더 탭을 선택합니다.
  4. 그룹의 Placeholder가 표시된 재할당 대기 서브탭으로 이동합니다.
  5. 각 placeholder 사용자의 상태를 재할당 상태 열에서 확인합니다.

재할당 상태로 필터링할 수 있습니다:

  1. 필터 드롭다운 목록에서 상태를 선택합니다.
  2. 사용 가능한 상태 중 하나를 선택합니다.

재할당 대기 탭에서 가능한 상태는 다음과 같습니다:

  • 시작하지 않음 - 재할당이 시작되지 않았습니다.
  • 승인 대기 중 - 재할당이 사용자 승인을 기다리고 있습니다.
  • 재할당 중 - 재할당이 진행 중입니다.
  • 거부됨 - 사용자가 재할당을 거부했습니다.
  • 실패 - 재할당이 실패했습니다.

재할당된 탭에서 가능한 상태는 다음과 같습니다:

  • 성공 - 재할당이 성공했습니다.
  • placeholder로 유지 - Placeholder 사용자가 영구적으로 유지되었습니다.

테이블은 기본적으로 placeholder 사용자 이름의 알파벳 순으로 정렬됩니다. 또한 재할당 상태에 따라 테이블을 정렬할 수 있습니다:

  1. 정렬 드롭다운 목록에서 선택합니다.
  2. 재할당 상태를 선택합니다.

기여 재할당 수락

수락 프로세스가 진행되었음을 알리는 이메일을 받을 수 있으며, 기여를 자신에게 재할당할 것을 확인해야 합니다.

이 임포트 프로세스에 대해 알림을 받았다면, 재할당 세부 정보를 매우 신중하게 검토해야합니다. 이메일에 나열된 세부 정보는 다음과 같습니다:

  • 임포트된 곳 - 가져온 콘텐츠의 플랫폼. 예를 들어, GitLab의 다른 인스턴스, GitHub 또는 Bitbucket입니다.
  • 원본 사용자 - 소스 플랫폼에서의 사용자의 이름 및 사용자 이름. 이것은 해당 플랫폼에서의 귀하의 이름과 사용자 이름일 수 있습니다.
  • 가져온 곳 - GitLab 인스턴스의 이름. 이것은 GitLab만 가능합니다.
  • 재할당된 위치 - GitLab 인스턴스의 전체 이름 및 사용자 이름.
  • 재할당한 사람 - 가져오기를 수행한 동료 또는 관리자의 전체 이름 및 사용자 이름입니다.

기여 재할당 거절

자신에게 기여를 재할당하기 위한 이메일을 받고 해당 정보가 인식되지 않거나 정보에 실수를 발견한 경우:

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

보안 고려사항

재할당 요청의 세부 정보를 매우 신중하게 검토해야 합니다. 신뢰할 수 있는 동료나 관리자에게서 이미이 프로세스에 대해 알려지지 않았다면, 추가로 주의해야 합니다.

의심이 드는 재할당을 받아들이지 말고 다음과 같이 조치하세요:

  1. 이메일에 대해 조치하지 마세요.
  2. 신뢰할 수 있는 동료나 관리자와 이야기하세요.

신뢰할 수 있는 사용자로부터만 재할당을 수락하세요. 기여 재할당은 영구적이며 되돌릴 수 없습니다. 재할당을 수락하면 기여가 잘못되게 귀하에게 속도될 수 있습니다.

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

프로젝트 가져오기 기록 보기

여러분이 만든 모든 프로젝트 가져오기를 볼 수 있습니다. 이 목록에는 다음이 포함됩니다:

  • 외부 시스템에서 가져온 경우 원본 프로젝트의 경로 또는 GitLab 프로젝트가 이전된 경우 가져오기 방법.
  • 대상 프로젝트의 경로.
  • 각 가져오기의 시작 날짜.
  • 각 가져오기의 상태.
  • 발생한 오류의 세부 정보.

프로젝트 가져오기 기록을 보려면:

  1. GitLab에 로그인합니다.
  2. 왼쪽 사이드바에서 맨 위에 있는 새로 만들기 () 및 새 프로젝트/저장소를 선택합니다.
  3. 프로젝트 가져오기를 선택합니다.
  4. 오른쪽 상단의 기록 링크를 선택합니다.
  5. 특정 가져오기에 오류가 있는 경우 세부 정보를 선택하여 확인합니다.

이 기록에는 내장 또는 사용자 정의 템플릿에서 만든 프로젝트도 포함됩니다. GitLab은 URL별로 저장소 가져오기를 사용하여 템플릿에서 새 프로젝트를 만듭니다.

LFS 객체를 포함한 프로젝트 가져오기

LFS 객체를 포함한 프로젝트를 가져올 때, 프로젝트에 lfs.url과 다른 URL 호스트를 가진 .lfsconfig 파일이 있는 경우 LFS 파일은 다운로드되지 않습니다.

프로페셔널 서비스를 활용한 이전

원한다면 직접 하는 대신 GitLab 프로페셔널 서비스를 활용하여 그룹과 프로젝트를 GitLab으로 이전할 수 있습니다. 자세한 정보는 프로페셔널 서비스 전체 카달로그를 참조하십시오.

문제 해결

가져온 저장소에 브랜치가 누락되어 있음

가져온 저장소에 원본 저장소의 모든 브랜치가 포함되지 않는 경우:

  1. 환경 변수 IMPORT_DEBUG=true를 설정합니다.
  2. 다른 그룹, 하위 그룹 또는 프로젝트 이름으로 가져오기를 다시 시도합니다.
  3. 여전히 일부 브랜치가 누락된 경우 importer.log를 검사합니다. (예: jq를 사용하여)

예외: Error Importing repository - No such file or directory @ rb_sysopen - (파일 이름)

이 오류는 저장소의 소스 코드를 tar.gz 파일 다운로드로 가져오려고 시도하는 경우 발생합니다.

가져오기에는 저장소 다운로드 파일만으로 충분하지 않고 GitLab 내보내기 파일이 필요합니다.