그룹 및 프로젝트 가져오기 및 마이그레이션

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은 이러한 지원되는 가져오기 소스에서 프로젝트를 가져올 수 있습니다.

가져오기 소스 설명
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. 왼쪽 사이드바에서 아래쪽으로 Admin을 선택합니다.
  2. Settings > General을 선택합니다.
  3. Import and export settings를 확장합니다.
  4. Import sources로 스크롤합니다.
  5. 필요하지 않은 가져오기 도구에 대한 체크박스를 지웁니다.

기타 가져오기 소스

다음의 다른 가져오기 소스에서 가져오는 정보도 읽을 수 있습니다:

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

GitLab은 Subversion 리포지토리를 Git으로 자동으로 마이그레이션할 수 없습니다. Subversion 리포지토리를 Git으로 변환하는 것은 어려울 수 있지만, 다음과 같은 여러 도구가 있습니다:

  • git svn, 매우 작고 기본적인 리포지토리용입니다.
  • reposurgeon, 더 크고 복잡한 리포지토리용입니다.

사용자 기여 및 멤버십 매핑

Status: Experiment
이 기능의 가용성은 기능 플래그에 의해 제어됩니다.

자세한 내용은 기록을 참조하세요.

이 기능은 내부 테스트 전용으로, 생산 환경에서는 사용할 준비가 되어 있지 않습니다.

사용자 기여 및 멤버십 매핑을 사용하면 마이그레이션이 완료된 후 사용자에게 수입된 기여 및 멤버십을 할당할 수 있습니다. 이전의 사용자 기여 및 멤버십 매핑 방법과는 달리, 마이그레이션 전에 준비가 필요하지 않습니다.

이 과정은 이메일 주소에 의존하지 않으므로, 소스 인스턴스와 대상 인스턴스에 서로 다른 이메일을 가진 사용자에 대해 기여를 매핑할 수 있습니다.

note
이 새로운 사용자 기여 및 멤버십 방법은 직접 전송을 사용한 마이그레이션만 지원됩니다. 직접 전송 마이그레이션을 위한 다른 사용자 기여 및 멤버십 매핑 방법에 대한 정보는 사용자 기여 및 멤버십 매핑을 참조하세요.

대상 인스턴스에서 매핑이 할당된 각 사용자는:

이 기능은 실험입니다. 버그를 발견하면 에픽 12378에 문제를 열어주세요.

요구 사항

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

플레이스홀더 사용자

대상 인스턴스의 사용자에게 즉시 기여 및 멤버십을 할당하는 대신, 가져온 기여 또는 멤버십이 있는 모든 사용자에 대해 플레이스홀더 사용자가 생성됩니다.

기여와 멤버십은 먼저 이러한 플레이스홀더 사용자에게 할당되며, 가져온 후 대상 인스턴스의 기존 사용자에게 재할당할 수 있습니다.

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

플레이스홀더 사용자 속성

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

  • 로그인.
  • 작업을 수행합니다. 예: 파이프라인 실행.
  • 문제 및 병합 요청의 지정자 또는 검토자로 제안에 나타납니다.
  • 프로젝트 및 그룹의 회원이 될 수 없습니다.

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

  • 새 플레이스홀더 사용자가 필요한지 결정하는 데 사용되는 고유 식별자(source_user_id).
  • 소스 호스트 이름 또는 도메인(source_hostname).
  • 기여 재할당에 도움을 주기 위한 소스 사용자의 이름(source_name).
  • 기여 재할당 중 그룹 소유자를 원활하게 하기 위한 소스 사용자의 사용자 이름(source_username).
  • 플레이스홀더를 생성한 가져오기 유형(import_type).

기록적 맥락을 보존하기 위해, 플레이스홀더 사용자 이름과 사용자 이름은 소스 사용자 이름과 사용자 이름에서 유래됩니다:

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

플레이스홀더 사용자 보기

선행 조건:

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

플레이스홀더 사용자는 그룹 또는 프로젝트가 가져오는 동안 대상 인스턴스에서 생성됩니다.

최상위 그룹과 해당 하위 그룹으로 가져오는 동안 생성된 플레이스홀더 사용자를 보려면:

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

플레이스홀더 사용자 제한

플레이스홀더 사용자는 가져오기 소스 및 최상위 그룹마다 생성됩니다:

  • 동일한 프로젝트를 두 번 가져와도 대상 인스턴스의 같은 최상위 그룹에 가져오는 경우, 두 번째 가져오기에서는 첫 번째 가져오기와 동일한 플레이스홀더 사용자를 사용합니다.
  • 동일한 프로젝트를 두 번 가져오지만 대상 인스턴스의 다른 최상위 그룹에 가져오는 경우, 두 번째 가져기는 해당 최상위 그룹 아래에 새로운 플레이스홀더 사용자를 생성합니다.

GitLab.com에 가져오는 경우, 플레이스홀더 사용자는 대상 인스턴스의 최상위 그룹당 제한됩니다. 제한은 귀하의 요금제 및 좌석 수에 따라 다릅니다. 플레이스홀더 사용자는 라이센스 제한에 포함되지 않습니다.

GitLab.com 요금제 좌석 수 최상위 그룹의 플레이스홀더 사용자 제한
Free 및 모든 체험판 모든 양 200
Premium < 100 500
Premium 101-500 2000
Premium 501 - 1000 4000
Premium > 1000 6000
Ultimate 및 오픈 소스 < 100 1000
Ultimate 및 오픈 소스 101-500 4000
Ultimate 및 오픈 소스 501 - 1000 6000
Ultimate 및 오픈 소스 > 1000 8000

레거시 브론즈, 실버 또는 골드 요금제의 고객은 해당하는 Free, Premium 또는 Ultimate 제한을 갖습니다.

Ultimate를 사용해보려는 Premium 고객(Ultimate 체험판 유료 고객 계획)에게는 Premium 제한이 적용됩니다.

이러한 제한이 가져오기에는 충분하지 않은 경우, GitLab 지원에 문의하세요.

위 제한은 GitLab.com에 해당합니다. 셀프 관리 GitLab은 기본적으로 플레이스홀더 제한이 없습니다. 셀프 관리 인스턴스 관리자는 자신의 설치에 대한 플레이스홀더 제한을 설정할 수 있습니다.

기여도 및 구성원 재지정

플레이스홀더 사용자로부터 기존 활성(비봇) 사용자에게 기여도 및 구성원을 재지정하는 작업은 대상 인스턴스에서 발생합니다. 대상 인스턴스에서 다음을 수행할 수 있습니다:

처음에 단일 플레이스홀더 사용자에게 할당된 모든 기여도는 대상 인스턴스에서 단일 활성 일반 사용자에게만 재지정할 수 있습니다. 단일 플레이스홀더 사용자에게 할당된 기여도를 여러 활성 일반 사용자에게 분할할 수 없습니다.

원본 인스턴스의 봇 사용자 기여도 및 구성원은 대상 인스턴스의 봇 사용자에게 재지정할 수 없습니다. 원본 봇 사용자 기여도를 플레이스홀더 사용자에게 할당된 상태로 유지할 수 있습니다.

재지정 요청을 받은 사용자는:

  • 요청을 수락할 수 있습니다. 모든 기여도 및 회원은 이전에 플레이스홀더 사용자에게 귀속되었던 것이 수락하는 사용자에게 다시 귀속됩니다. 이 프로세스는 기여도 수에 따라 몇 분이 걸릴 수 있습니다.
  • 요청을 거부하거나 스팸으로 신고할 수 있습니다. 이 옵션은 재지정 요청 이메일에서 사용할 수 있습니다.

향후 가져오기에서는 동일한 원본 사용자에게 속하는 기여도 및 구성원이 이전에 해당 원본 사용자에 대한 재지정을 수락한 사용자에게 자동으로 매핑됩니다.

재지정 프로세스가 완료되기 전에 다음 작업을 수행할 수 없습니다:

프로세스가 완료되지 않으면, 플레이스홀더 사용자에게 여전히 할당된 기여도는 실제 사용자에게 재지정될 수 없으며, 플레이스홀더 사용자에게 연결된 상태로 남게 됩니다.

보안 고려 사항

이 기여 및 멤버십 재배정이 완료되면 되돌릴 수 없으므로 시작하기 전에 모든 내용을 확인하세요.

잘못된 사용자에게 기여 및 멤버십을 재배정하는 것은 보안 위협이 될 수 있습니다. 왜냐하면 사용자가 귀하의 그룹의 멤버가 되기 때문입니다.

이들은 따라서 보아서는 안 되는 정보를 볼 수 있습니다.

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

멤버십 보안 고려 사항

GitLab 권한 모델 때문이며, 그룹이나 프로젝트가 기존 상위 그룹에 가져올 때, 상위 그룹의 구성원은 가져온 그룹이나 프로젝트에 상속된 멤버십을 부여받습니다.

기여 및 멤버십 재배정을 위해 이미 가져온 그룹이나 프로젝트의 상속된 멤버십이 있는 사용자를 선택하는 것은 이들의 멤버십 재배정에 영향을 미칠 수 있습니다.

GitLab은 자식 프로젝트나 그룹에서 상속된 멤버십보다 낮은 역할을 가진 멤버십을 허용하지 않습니다. 할당된 사용자의 가져온 멤버십이 기존 상속된 멤버십보다 낮은 역할을 가지면, 가져온 멤버십은 사용자에게 재배정되지 않습니다.

이로 인해 가져온 그룹이나 프로젝트의 멤버십이 소스보다 높게 유지됩니다.

UI에서 재배정 요청

전제 조건:

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

기여 및 멤버십 재배정 수락을 사용자가 요청하려면:

  1. 왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.

  2. Manage > Members를 선택합니다.

  3. Placeholders 탭을 선택합니다.

  4. 기다리고 있는 재배정인 Awaiting reassignment 하위 탭으로 이동하면, 테이블에 플레이스홀더가 나열됩니다.

  5. 각 플레이스홀더에 대해 테이블 열 Placeholder user 및 Source에서 정보를 검토합니다.

  6. Reassign placeholder to 열에서 드롭다운 목록에서 사용자를 선택합니다.

  7. Reassign을 선택합니다.

하나의 플레이스홀더 사용자에 대한 기여만 활성 비봇 사용자에게 재배정할 수 있습니다.

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

플레이스홀더로 유지

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

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

플레이스홀더 사용자의 이름과 사용자 이름은 소스 사용자의 이름과 사용자 이름과 유사하므로 많은 역사적 맥락을 유지할 수 있습니다.

남아 있는 플레이스홀더 사용자를 플레이스홀더로 유지하면, 나중에 실제 사용자에게 기여를 재배정할 수 없음을 기억하세요. 나머지 플레이스홀더 사용자를 플레이스홀더로 유지하기 전에 모든 필수 재배정이 완료되도록 하세요.

플레이스홀더 사용자에게 할당된 기여를 하나씩 또는 일괄적으로 유지할 수 있습니다.

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

  1. 왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.

  2. Manage > Members를 선택합니다.

  3. Placeholders 탭을 선택합니다.

  4. 기다리고 있는 재배정인 Awaiting reassignment 하위 탭으로 이동하면, 테이블에 플레이스홀더가 나열됩니다.

  5. Placeholder user 및 Source 열을 검토하여 유지하려는 플레이스홀더 사용자를 찾습니다.

  6. Reassign placeholder to 열에서 Don’t reassign을 선택합니다.

  7. Confirm을 선택합니다.

플레이스홀더 사용자를 일괄적으로 유지하려면:

  1. 왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.

  2. Manage > Members를 선택합니다.

  3. Placeholders 탭을 선택합니다.

  4. Reassign with CSV 옆의 More options icon을 선택합니다.

  5. Keep all as placeholder 옵션을 선택합니다.

  6. 확인 대화 상자에서 Confirm을 선택합니다.

재배정 요청 취소

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.

  2. 관리 > 구성원을 선택합니다.

  3. 자리 표시자 탭을 선택합니다.

  4. 자리 표시자가 테이블에 나열된 재배정 대기 하위 탭으로 이동합니다.

  5. 올바른 행에서 취소를 선택합니다.

보류 중인 재배정 요청에 대해 사용자에게 다시 알리기

사용자가 재배정 요청에 대해 행동하지 않는 경우, 다른 이메일을 보내 그들에게 다시 알릴 수 있습니다:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.

  2. 관리 > 구성원을 선택합니다.

  3. 자리 표시자 탭을 선택합니다.

  4. 자리 표시자가 테이블에 나열된 재배정 대기 하위 탭으로 이동합니다.

  5. 올바른 행에서 알림을 선택합니다.

재배정 상태에 따라 보기, 필터링 및 정렬

재배정 프로세스가 아직 완료되지 않은 모든 자리 표시자 사용자의 상태를 검토할 수 있습니다:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.

  2. 관리 > 구성원을 선택합니다.

  3. 자리 표시자 탭을 선택합니다.

  4. 자리 표시자가 테이블에 나열된 재배정 대기 하위 탭으로 이동합니다.

  5. 재배정 상태 열에서 각 자리 표시자 사용자의 상태를 확인합니다.

재배정 상태별로 필터링할 수 있습니다:

  1. 필터 드롭다운 목록에서 상태를 선택합니다.

  2. 사용 가능한 상태 중 하나를 선택합니다.

재배정 대기 탭의 가능한 상태는 다음과 같습니다:

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

재배정 완료 탭의 가능한 상태는 다음과 같습니다:

  • 성공 - 재배정이 성공했습니다.
  • 자리 표시자로 유지 - 자리 표시자 사용자가 영구적으로 만들어졌습니다.

기본적으로 테이블은 자리 표시자 사용자 이름에 대해 알파벳 순으로 정렬됩니다. 재배정 상태에 따라 테이블을 정렬할 수도 있습니다:

  1. 정렬 드롭다운 목록을 선택합니다.

  2. 재배정 상태를 선택합니다.

기여 재배정 수락

가끔 기여를 자신에게 재배정하라는 이메일을 받을 수 있습니다.

이러한 수입 프로세스에 대해 통보를 받았다면, 재배정 세부 정보를 매우 주의해서 검토해야 합니다. 이메일에 나열된 세부 정보는 다음과 같습니다:

  • 가져온 곳 - 가져온 콘텐츠의 출처 플랫폼입니다. 예를 들어, 다른 GitLab 인스턴스, GitHub 또는 Bitbucket입니다.
  • 원본 사용자 - 소스 플랫폼상의 사용자 이름과 성입니다. 이는 해당 플랫폼에서의 귀하의 이름과 사용자 이름일 수 있습니다.
  • 가져온 곳 - GitLab 인스턴스만 될 수 있는 새로운 플랫폼의 이름입니다.
  • 재배정된 사람 - GitLab 인스턴스에서 귀하의 전체 이름과 사용자 이름입니다.
  • 재배정한 사람 - 수입을 수행한 동료 또는 관리자의 전체 이름과 사용자 이름입니다.

기여 재배정 거부

기여를 자신에게 재배정하라는 확인 요청 이메일을 받고 이 정보가 인식되지 않거나 오류가 있는 경우:

  1. 절대 진행하지 않거나 기여 재배정을 거부합니다.

  2. 신뢰할 수 있는 동료나 관리자에게 이야기합니다.

보안 고려사항

재배치 요청의 재배치 세부 정보를 매우 주의 깊게 검토해야 합니다. 신뢰할 수 있는 동료나 관리자로부터 이 프로세스에 대해 미리 알림을 받지 못한 경우, 추가로 주의하십시오.

의심스러운 재배치를 수락하는 대신에:

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

신뢰하고 아는 사용자로부터만 재배치를 수락하십시오. 기여의 재배치는 영구적이며 되돌릴 수 없습니다. 재배치를 수락하면 기여가 잘못 귀속될 수 있습니다.

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

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

자신이 만든 모든 프로젝트 가져오기를 볼 수 있습니다. 이 목록은 다음을 포함합니다:

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

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

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

기록에는 내장 또는 사용자 정의 템플릿에서 생성된 프로젝트도 포함됩니다. GitLab은 템플릿에서 새 프로젝트를 생성하기 위해 URL로 리포지토리 가져오기를 사용합니다.

LFS 객체가 있는 프로젝트 가져오기

LFS 객체가 포함된 프로젝트를 가져올 때, 프로젝트에 URL 호스트(lfs.url)가 리포지토리 URL 호스트와 다른 .lfsconfig 파일이 있는 경우, LFS 파일이 다운로드되지 않습니다.

전문 서비스에 의한 마이그레이션

원하는 경우, 직접 작업하는 대신 GitLab 전문 서비스에 참여하여 그룹과 프로젝트를 GitLab으로 마이그레이션할 수 있습니다. 자세한 내용은 전문 서비스 전체 카탈로그를 참조하세요.

문제 해결

가져온 리포지토리에 브랜치가 누락됨

가져온 리포지토리에 소스 리포지토리의 모든 브랜치가 포함되어 있지 않은 경우:

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

예외: 리포지토리 가져오기 오류 - 파일이나 디렉토리가 없습니다 @ rb_sysopen - (파일명)

리포지토리의 소스 코드를 다운로드한 tar.gz 파일을 가져오려고 하면 이 오류가 발생합니다.

가져오려면 GitLab 내보내기 파일이 필요하며, 단순히 리포지토리 다운로드 파일만으로는 불가능합니다.