GitHub 제품 간 마이그레이션의 개요

개요

GitHub Enterprise Importer을(를) 사용하여 GitHub Enterprise Cloud(으)로 마이그레이션할 수 있습니다. 자세한 내용은 "GitHub Enterprise Importer 정보"을 참조하세요.

GitHub 제품 간에, GitHub Enterprise Server에서 GitHub Enterprise Cloud(으)로 마이그레이션하는 경우 이 가이드를 사용하여 마이그레이션을 계획 및 구현하고 후속작업을 완료할 수 있습니다. 지원되는 마이그레이션 경로의 전체 목록은 "GitHub Enterprise Importer 정보"을 참조하세요.

마이그레이션 계획

마이그레이션을 계획하기 위해선, 다음 질문을 스스로에게 묻습니다.

• 조직 또는 리포지토리를 통해 마이그레이션하시겠습니까?
• 마이그레이션을 얼마나 빨리 완료해야 합니까?
• 마이그레이션할 내용을 이해합니까?
• 마이그레이션을 실행할 사람은 누구입니까?
• 마이그레이션 후 유사한 조직 구조를 관리하시겠습니까?

조직 또는 리포지토리를 통해 마이그레이션하시겠습니까?

먼저 마이그레이션 원본과 대상이 모두 GitHub.com인 경우 조직별로 또는 리포지토리별로 마이그레이션할지 결정합니다.

리포지토리별 마이그레이션을 선택하는 경우 리포지토리별 데이터만 마이그레이션됩니다. 조직별 마이그레이션 전략을 선택하는 경우 팀 및 리포지토리에 대한 액세스를 포함하여 선택한 조직 수준 데이터도 마이그레이션됩니다.

그러나 조직을 마이그레이션하는 경우 원본 조직이 소유한 모든 리포지토리가 동시에 마이그레이션됩니다. 리포지토리를 일괄 처리로 중단하거나 조직의 리포지토리 마이그레이션을 건너뛸 수 없습니다. 리포지토리 수가 많거나 모든 리포지토리의 가동 중지 시간을 동시에 허용할 수 없는 경우 대신 리포지토리 마이그레이션을 실행해야 할 수 있습니다.

또한 조직 마이그레이션은 대상 엔터프라이즈 계정에서 새 조직을 만듭니다. 리포지토리를 기존 조직으로 마이그레이션하려면 리포지토리 마이그레이션을 대신 실행해야 합니다.

마지막으로, 조직을 마이그레이션하려면 대상 엔터프라이즈 계정의 엔터프라이즈 소유자여야 합니다. 엔터프라이즈 소유자가 아닌 사람에게 마이그레이션을 수행하려면 리포지토리 마이그레이션을 실행해야 합니다.

마이그레이션을 얼마나 빨리 완료해야 합니까?

타임라인을 결정합니다. 이는 주로 접근 방식을 결정합니다. 타임라인을 결정하는 첫 번째 단계는 마이그레이션해야 하는 항목의 인벤토리를 가져오는 것입니다. 이 데이터를 수집하려면 GitHub CLI의 gh-repo-stats확장을 사용합니다. 이 오픈 소스 도구는 조직에 마이그레이션할 데이터양을 자세히 나타내는 보고서를 생성합니다.

• 리포지토리 수
• 끌어오기 요청 수
• 문제의 수
• 사용자 수
• 프로젝트 및 Wiki 사용량

마이그레이션 시기는 주로 리포지토리의 끌어오기 요청 수 및 문제를 기반으로 합니다. 1,000개의 리포지토리를 마이그레이션하려는 경우 각 리포지토리에는 평균 100개의 끌어오기 요청 및 문제가 있으며 50명의 사용자만 리포지토리에 기여한 경우 마이그레이션이 매우 빠를 수 있습니다. 100개의 리포지토리만 마이그레이션하려고 하지만 리포지토리에 각각 평균 75,000개의 끌어오기 요청 및 문제가 있고 5,000명의 사용자가 있는 경우 마이그레이션 시간이 더 오래 걸리고 훨씬 더 많은 계획 및 테스트가 필요합니다.

분석기를 사용한 후에는, 원하는 타임라인에 대해 재고 데이터의 무게를 측정할 수 있습니다. 조직에서 더 높은 수준의 변화를 견딜 수 있는 경우, 모든 리포지토리를 한 번에 마이그레이션하여 며칠 안에 마이그레이션 작업을 완료할 수도 있습니다. 그러나 동시에 마이그레이션할 수 없는 다양한 팀 역시 있을 수 있습니다. 이 경우 팀의 타임라인에 맞게 마이그레이션을 일괄 처리하고 스테이징하여 마이그레이션 노력을 확장할 수 있습니다.

1. GitHub CLI에 대한 gh-repo-stats확장을 사용한 다음 마이그레이션 인벤토리를 검토합니다.
2. 팀이 마이그레이션할 준비가 된 시기를 이해하려면, 관련자를 인터뷰합니다.
3. 이 가이드의 나머지 부분을 완전히 검토한 다음 마이그레이션 타임라인을 결정합니다.

마이그레이션할 내용을 이해합니까?

귀하와 관련자가 GitHub Enterprise Importer에서 마이그레이션할 수 있는 데이터를 이해하도록 해야 합니다.

1. 마이그레이션 원본에 대해 마이그레이션된 데이터를 검토합니다. 자세한 내용은 "GitHub 제품 간 마이그레이션 정보"을(를) 참조하세요.
2. 수동으로 마이그레이션하거나 다시 생성해야 하는 데이터 목록을 만듭니다.

마이그레이션을 실행할 사람은 누구입니까?

마이그레이션을 실행할 개인을 결정하고 이 개인에게 필요한 액세스 권한이 있는지 확인합니다. 옵션은 조직 또는 리포지토리별로 마이그레이션하는지에 따라 달라집니다.

조직 마이그레이션을 실행할 사람 결정

조직을 마이그레이션하려면 원본 조직의 조직 소유자가 되거나 조직 소유자가 해당 조직에 대한 마이그레이션자 역할을 부여해야 합니다.

또한 대상 엔터프라이즈 계정의 엔터프라이즈 소유자여야 합니다. 엔터프라이즈 계정에 대한 마이그레이션자 역할을 부여할 수 없습니다.

1. 마이그레이션을 실행할 사람이 대상 엔터프라이즈 계정의 엔터프라이즈 소유자인지 확인합니다.
2. 해당 개인이 원본 조직의 조직 소유자 아닌 경우 조직에 대한 마이그레이션자 역할을 부여합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.
3. 사용자가 모든 액세스 요구 사항을 충족하도록 personal access token을(를) 올바르게 구성했는지 확인합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을 참조하세요.

리포지토리 마이그레이션을 실행할 사람 결정

리포지토리를 마이그레이션하려면 원본 조직과 대상 조직 모두에 대한 조직 소유자가 되거나 조직 소유자가 아닌 각 조직에 대한 마이그레이션자 역할을 부여해야 합니다.

1. 조직 소유자가 마이그레이션을 수행할지 또는 다른 사람에게 마이그레이션자 역할을 부여해야 할지를 결정합니다.

2. 마이그레이션자 역할을 부여하도록 선택한 경우, 역할을 부여할 사람 또는 팀을 결정합니다.

3. 사용자 또는 팀에 마이그레이션자 역할을 부여합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을 참조하세요.

   참고: 원본 조직과 대상 조직 모두에 대해 마이그레이션자 역할을 부여해야 합니다.

4. 사용자가 모든 액세스 요구 사항을 충족하도록 personal access token을(를) 올바르게 구성했는지 확인합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을 참조하세요.

마이그레이션 후 유사한 조직 구조를 관리하시겠습니까?

다음으로 마이그레이션 후 유사한 조직 구조의 관리 여부를 고려합니다. 마이그레이션 활동을 일괄 처리로 중단하려는 경우 일괄 처리를 결정하는 데 도움이 됩니다. 원본 및 대상의 조직 간에 일대일 대응을 유지하려는 경우 조직별로 마이그레이션을 일괄 처리하는 것이 좋습니다. 이는 가장 간단한 방법입니다. 특히 GitHub.com에서 마이그레이션하는 경우 하나의 명령으로 전체 조직을 마이그레이션할 수 있기 때문입니다. 다른 소스에서 마이그레이션하는 경우 GitHub CLI은(는) 단일 조직의 모든 리포지토리를 마이그레이션하는 스크립트를 생성할 수 있습니다.

조직 구조를 변경하려는 경우 다른 일괄 처리 요소를 고려합니다. 유사한 팀 또는 비즈니스 부서가 소유한 리포지토리를 일괄 처리하거나 대상 조직에서 일괄 처리할 수 있습니다. 가능하면 팀에서 일괄 처리하는 것이 좋습니다. 비즈니스 부서 또는 대상 조직별로 일괄 처리하는 경우 관련된 관련자의 수가 늘어나 마이그레이션 기간이 더 단축될 수 있습니다.

조직 구조를 변경하더라도 마이그레이션을 위한 스크립트를 계속 준비할 수 있습니다. GitHub CLI 명령을 사용한 다음 필요에 따라 각 리포지토리의 라인을 다른 스크립트로 이동합니다.

1. 새로운 조직 구조를 결정합니다.
2. 마이그레이션 작업을 더 작은 일괄 처리로 분할해야 하는지에 대한 여부를 결정합니다.
3. 그렇다면, 마이그레이션을 중단하는 방법을 결정합니다.

마이그레이션 실행

계획을 완료한 후에, 실제 마이그레이션을 시작할 수 있습니다. 마이그레이션 중 및 마이그레이션 후에 엔터프라이즈에 고유할 수 있는 문제를 발견할 수 있도록 모든 마이그레이션의 평가판 실행을 수행하는 것을 권장합니다. 평가판 실행에서 발견된 문제를 해결한 후 생산 마이그레이션을 실행할 수 있습니다.

평가판 마이그레이션은 몇 가지 중요한 정보를 발견하는 데 도움이 됩니다.

• 지정된 리포지토리에 대한 마이그레이션이 성공적으로 완료될 수 있는지의 여부
• 사용자가 리포지토리를 작업을 성공적으로 시작할 수 있는 상태로 되돌릴 수 있는지의 여부
• 마이그레이션을 실행하는 데 걸리는 시간- 마이그레이션 일정을 계획하고 관련자의 기대치를 설정하는 데 유용합니다.

평가판 실행에는 시간 조정이 많이 필요하지 않습니다. GitHub Enterprise Importer은(는) 마이그레이션 중인 리포지토리의 사용자에게 가동 중지 시간이 필요하지 않습니다. 그러나 마이그레이션 중에 새 데이터가 생성되지 않도록 생산 마이그레이션 중에 작업을 중지하는 것이 좋습니다. 그러면 마이그레이션된 리포지토리에서 누락됩니다. 이는 평가판 마이그레이션에 대한 문제가 아니므로 평가판 실행은 언제든지 할 수 있습니다. 평가판 마이그레이션을 완료하는 데 걸리는 시간을 줄이기 위해 평가판 실행에 대한 배치를 다시 예약할 수 있습니다. 그런 다음, 해당 리포지토리의 사용자는 자신의 시간에 맞는 결과의 유효성을 검사할 수 있습니다.

리포지토리 마이그레이션의 경우 평가판 마이그레이션의 대상으로 사용할 테스트 조직을 만드는 것이 좋습니다. 모든 평가판 실행에 단일 조직을 사용하거나, 의도한 각 대상 조직에 대해 하나의 테스트 조직을 만들 수 있습니다. 조직이 프로덕션이 아닌 마이그레이션 유효성 검사를 위한 것임을 명확히 하려면 조직 이름의 끝에 -sandbox을(를) 포함시키는 것이 좋습니다. 완료한 후, 테스트 조직을 삭제할 수 있습니다.

1. 리포지토리 마이그레이션을 실행하는 경우 평가판 마이그레이션을 위한 테스트 조직을 만듭니다.
2. 원본 조직에서 IP 허용 목록을 사용하는 경우 GitHub Enterprise Importer별 액세스를 허용하도록 목록을 구성합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.
3. 평가판 마이그레이션을 실행합니다.
4. 평가판 마이그레이션을 위해 아래 설명된 후속 작업을 완료합니다.
5. 사용자에게 마이그레이션 결과가 유효한지 검사하도록 요청합니다.
6. 평가판 마이그레이션에서 발견한 문제를 해결합니다.
7. 대상에서 IP 허용 목록을 사용하는 경우 GitHub Enterprise Importer의 액세스를 허용하도록 목록을 구성합니다. 자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을 참조하세요.
8. 리포지토리 마이그레이션을 실행하고 GitHub Advanced Security 설정을 마이그레이션하려면 대상 조직에 대한 GitHub Advanced Security을(를) 사용하도록 설정합니다. 자세한 내용은 "조직의 보안 및 분석 설정 관리"을(를) 참조하세요.
9. 프로덕션 마이그레이션을 실행합니다. 자세한 내용은"GitHub Enterprise Importer 정보" 또는 "GitHub.com에서 GitHub Enterprise Cloud로 조직 마이그레이션"을 참조하세요.
10. 필요에 따라 테스트 조직을 삭제합니다.

후속 작업 완료

각 마이그레이션이 완료되면, 리포지토리가 작동할 준비가 되기 전에 몇 가지 추가 작업을 완료해야 합니다.

• 마이그레이션 상태 확인
• 마이그레이션 로그 검토
• Git LFS 개체 마이그레이션
• 리포지토리 표시 유형 설정
• GitHub Actions 구성
• IP 허용 목록 구성
• GitHub Advanced Security 관리
• 웹후크 사용
• GitHub Apps 다시 설치
• 팀 다시 생성
• 마네킹 회수

마이그레이션 상태 확인

먼저 마이그레이션이 성공했는지 실패했는지 확인합니다.

마이그레이션의 상태 검사 방법은 마이그레이션을 실행하는 방법에 따라 달라집니다.

• GitHub CLI를 사용하여 마이그레이션을 실행한 경우 기본적으로 마이그레이션이 완료되면 마이그레이션이 성공했는지 아니면 실패했는지 여부가 프로세스에 표시됩니다. 마이그레이션에 실패한 경우 실패 이유가 표시됩니다.

  Migration completed (ID: RM_123)! State: SUCCEEDED
  

• 선택적 --queue-only 인수와 함께 GitHub CLI를 사용하여 마이그레이션을 실행한 경우 마이그레이션을 대기한 직후 프로세스가 종료되고 마이그레이션이 성공했는지 또는 실패했는지는 알려주지 않습니다. wait-for-migration 명령을 사용하거나 마이그레이션 로그를 검토하여 마이그레이션의 상태 검사 수 있습니다.

• GraphQL API를 사용하여 마이그레이션을 실행한 경우 RepositoryMigration 개체의 state 필드와 failureReason 필드를 쿼리할 수 있습니다.

마이그레이션에 실패한 경우 마이그레이션 로그에 오류의 원인에 대한 추가 정보가 포함될 수 있습니다. 자세한 내용은 "마이그레이션 로그 검토"를 참조하세요.

마이그레이션 로그 검토

마이그레이션된 각 리포지토리에 대한 마이그레이션 로그를 검토합니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 마이그레이션 로그 액세스"을(를) 참조하세요.

마이그레이션에 실패한 경우 로그에 오류의 원인에 대한 추가 정보가 포함될 수 있습니다.

마이그레이션에 성공하면 마이그레이션 로그에 마이그레이션되지 않았거나 주의해야 마이그레이션된 특정 데이터 조각(예: 끌어오기 요청, 문제 또는 주석)을 나타내는 경고가 표시될 수 있습니다.

마이그레이션 경고 이해에 대한 자세한 내용은 "GitHub Enterprise Importer를 사용하여 마이그레이션 문제 해결"을 참조하세요. 마이그레이션 경고를 검토한 후에는 해당 경고를 수락하고 계속 진행할지 결정해야 합니다.

Git LFS 개체 마이그레이션

GitHub Enterprise Importer은(는) Git LFS 개체를 마이그레레이션하지 않습니다. 원본 리포지토리에서 Git LFS을(를) 사용하는 경우 Git LFS 개체를 로컬로 마이그레이션된 리포지토리에 수동으로 푸시할 수 있습니다. 자세한 내용은 "리포지토리 복제"을(를) 참조하세요.

리포지토리 표시 유형 설정

모든 리포지토리는 기본적으로 비공개로 마이그레이션되며 마이그레이션 및 조직 소유자가 실행한 사용자만 리포지토리에 액세스할 수 있습니다. 리포지토리를 비공개로 만들지 않기 위해선, 표시 유형을 변경합니다.

• --target-repo-visibility CLI 옵션 또는 targetRepoVisibility GraphQL 속성을 사용하여 리포지토리의 표시 여부를 설정할 수 있습니다.
• 브라우저에서 리포지토리의 표시 유형을 변경할 수 있습니다. 자세한 내용은 "리포지토리 표시 유형 설정"을(를) 참조하세요.
• 또는 GitHub CLI을(를) 사용하여 명령줄에서 리포지토리 표시 유형을 변경할 수 있습니다. 마이그레이션을 실행하기 위해 생성된 스크립트에 이 명령을 추가할 수 있습니다. 자세한 내용은 GitHub CLI 설명서의 “gh repo edit”을 참조하세요.

GitHub Actions 구성

리포지토리에서 GitHub Actions을(를) 사용하는 경우 워크플로는 Git 리포지토리의 일부로 자동으로 마이그레이션됩니다.

마이그레이션 프로세스 중에 워크플로가 실수로 트리거되지 않도록 마이그레이션된 모든 리포지토리에 대해 GitHub Actions이(가) 비활성화되지만 마이그레이션이 완료되면 GitHub Actions이(가) 다시 사용하도록 설정됩니다.

더 큰 실행기, 자체 호스트형 실행기 또는 암호화된 비밀을 사용하는 경우 다시 구성해야 합니다.

1. 자체 호스트형 실행기를 사용하는 경우 실행기를 다시 구성합니다.

   • 적절한 리포지토리, 조직 또는 엔터프라이즈에 실행기를 추가합니다. 자세한 내용은 "자체 호스트형 실행기 추가"을(를) 참조하세요.
   • 조직 또는 엔터프라이즈 수준에서 실행기를 사용하려면 워크플로를 업데이트합니다. 자세한 내용은 "워크플로에서 자체 호스트형 실행기 사용"을(를) 참조하세요.

2. 더 큰 실행기을(를) 사용하는 경우 실행기를 다시 구성합니다.

   • 실행기 그룹은 실행기에 대한 액세스를 제어하는 데 구성됩니다. 자세한 내용은 "더 큰 실행기 액세스 제어"을(를) 참조하세요.
   • 더 큰 실행기 설정 자세한 내용은 "대형 실행기 관리하기"을(를) 참조하세요.
   • 실행기를 가리키도록 워크플로를 업데이트합니다. 자세한 내용은 "더 큰 실행기에서 작업 실행"을(를) 참조하세요.

3. 암호화된 비밀을 다시 추가합니다.

   • 브라우저를 사용하려면 "GitHub Actions에서 비밀 사용"을 참조하세요.
   • GitHub CLI을(를) 사용하려면 GitHub CLI 설명서에서 gh secret을(를) 참조하세요.

4. 환경을 다시 구성합니다. 자세한 내용은 "배포 환경 관리"을(를) 참조하세요.

IP 허용 목록 구성

GitHub Enterprise Importer에 대한 IP 범위를 원본 또는 대상 조직의 IP 허용 목록에 추가한 경우 해당 항목을 제거할 수 있습니다. 대상 엔터프라이즈에 대한 ID 공급자의 IP 허용 목록 제한을 사용하지 않도록 설정했을 경우, 지금 다시 사용하도록 설정할 수 있습니다.

자세한 내용은 "GitHub 제품 간의 마이그레이션에 대한 액세스 관리"을(를) 참조하세요.

GitHub Advanced Security 관리

리포지토리를 마이그레이션하기 전에 대상 조직에 GitHub Advanced Security을(를) 사용하도록 설정한 경우 개별 기능에 대한 설정이 마이그레이션되었습니다. 그렇지 않은 경우 마이그레이션 후 개별 기능을 다시 사용하도록 설정해야 합니다. 자세한 내용은 "리포지토리에 대한 보안 및 분석 설정 관리"을(를) 참조하세요.

각 기능에 대한 추가적인 마이그레이션 후 단계가 있습니다.

Secret scanning

대상 리포지토리에 대해 비밀 검사를 사용하도록 설정하면 전체 리포지토리의 검사가 수행됩니다. 검사가 완료되면 모든 경고가 채워지지만 수정 상태는 없습니다.

REST API를 사용하여 원본 리포지토리의 수정을 미러링하도록 경고를 업데이트할 수 있습니다. 자세한 내용은 "비밀 검사를 위한 REST API 엔드포인트"을(를) 참조하세요.

이러한 업데이트된 수정과 연결된 사용자는 원본 리포지토리에서 경고를 수정한 사용자가 아니라 API 호출에 사용된 personal access token을(를) 소유한 사용자이며, 수정과 관련된 날짜는 원본 리포지토리에서 경고가 수정된 날짜가 아니라 API 호출 날짜입니다.

Code scanning

Code scanning 경고는 GitHub Enterprise Importer에 따라 마이그레이션되지 않습니다. 그러나 경고는 원본 리포지토리에서 SARIF 데이터로 사용할 수 있습니다. REST API를 사용하여 이 데이터를 대상 리포지토리에 업로드할 수 있습니다. 자세한 내용은 "코드 검색에 대한 REST API 엔드포인트"을(를) 참조하세요.

이 방법으로 채워진 Code scanning 경고는 원본 리포지토리의 원래 경고와 다릅니다.

• 경고에는 원본 리포지토리의 전체 타임라인 아니라 경고의 검색 및 최신 상태만 포함됩니다.
• 경고는 open 또는 fixed로만 식별됩니다. 다른 수정 상태(예: dismissed 및 reopened)는 손실됩니다.
• 경고의 모든 이벤트에 대한 날짜는 원래 이벤트가 원본 리포지토리에서 발생한 날짜가 아니라 API 호출 날짜입니다.
• 경고 작성자와 같은 모든 행위자는 API 호출에 사용되는 personal access token의 소유자로 변경됩니다.

Dependabot alerts

Dependabot alerts 및 종속성 그래프가 사용하도록 설정되면 Dependabot alerts이(가) 기본 분기의 현재 상태에서 다시 빌드됩니다. 이러한 경고의 수정 상태는 마이그레이션되지 않으며 이전 경고도 마이그레이션되지 않습니다.

Dependabot에 대해 암호화된 비밀을 다시 추가해야 합니다. 자세한 내용은 "Dependabot에 대한 개인 레지스트리 액세스 구성"을(를) 참조하세요.

웹후크 사용

원본 리포지토리의 모든 활성 웹후크가 마이그레이션됩니다. 그러나 마이그레이션된 웹후크는 기본적으로 사용하지 않도록 설정됩니다. 리포지토리 설정에서 이러한 웹후크를 다시 사용하도록 설정할 수 있습니다.

1. 마이그레이션된 리포지토리의 설정으로 이동합니다.
2. 사이드바의 "코드 및 자동화" 섹션에서 웹후크를 클릭합니다.
3. 사용하도록 설정할 웹후크의 오른쪽에서 편집을 클릭합니다.
4. 비밀 토큰을 사용하여 웹후크를 보호하는 경우 "비밀"에서 비밀을 다시 추가합니다.
5. 페이지의 아래쪽에서 활성을 선택합니다.
6. 웹후크 업데이트를 클릭합니다.

GitHub Apps 다시 설치

원본 리포지토리에 GitHub Apps이(가) 설치된 경우 마이그레이션된 리포지토리에 다시 설치해야 합니다. 자세한 내용은 "자신만의 GitHub 앱 설치"을(를) 참조하세요.

팀 다시 생성

조직별로 마이그레이션한 경우 팀 멤버십만 복구하면 됩니다. 리포지토리별로 마이그레이션한 경우 팀을 다시 만들고 해당 팀에게 리포지토리에 대한 액세스 권한을 부여한 다음 팀 멤버십을 복구해야 합니다.

조직 마이그레이션을 위한 팀 다시 만들기

티 및 해당 리포지토리 액세스는 조직 마이그레이션의 일부로 마이그레이션되지만 팀 멤버십은 마이그레이션되지 않습니다. 마이그레이션 후에는 마이그레이션된 팀에 사용자를 추가해야 합니다.

ID 공급자(IdP)를 통해 팀 멤버십을 관리하려면 팀 동기화를 사용하는 것이 좋습니다. 자세한 내용은 "SCIM 프로비저닝을 구성하여 사용자 관리" 또는 Enterprise Managed Users, "엔터프라이즈의 조직에 대한 팀 동기화 관리"을 사용하지 않는 엔터프라이즈를 참조하세요.

그렇지 않으면 조직에 구성원을 수동으로 추가한 다음, 팀에 조직 구성원을 추가할 수 있습니다. 자세한 내용은 "팀에 조직 멤버 추가"을(를) 참조하세요.

리포지토리 마이그레이션을 위한 팀 다시 생성

팀은 리포지토리 마이그레이션의 일부로 마이그레이션되지 않습니다. 수동으로 팀을 다시 만들고 각 팀에게 리포지토리에 대한 액세스 권한을 부여해야 합니다.

1. 팀을 다시 만듭니다. 자세한 내용은 "팀 만들기"을(를) 참조하세요.
2. 팀에 조직 구성원을 추가합니다. 자세한 내용은 "팀에 조직 멤버 추가"을(를) 참조하세요.
3. 각 팀에 리포지토리에 대한 액세스 권한을 부여합니다. 자세한 내용은 "조직 리포지토리에 대한 팀 액세스 관리"을(를) 참조하세요.

마네킹 회수

GitHub Enterprise Importer을(를) 사용하여 마이그레이션을 실행하면, 마이그레이션된 리포지토리의 모든 사용자 활동(Git 커밋 제외)은 마네킹이라는 자리 표시자 ID에 기인합니다.

GitHub CLI을(를) 사용하거나 브라우저에서 각 마네킹의 기록을 조직 구성원에게 다시 배포할 수 있습니다. GitHub CLI을(를) 사용하는 경우 마네킹을 대량으로 회수할 수 있습니다. 자세한 내용은 "GitHub Enterprise Importer에 대한 마네킹 회수"을 참조하세요.

1. 마네킹을 회수할지에 대한 여부를 결정합니다.
2. 회수를 완료할 때를 계획합니다.
3. 마네킹을 회수합니다.
4. 구성원 중 팀 멤버 자격을 통해 리포지토리에 대한 적절한 액세스 권한이 아직 없는 경우, 구성원에게 리포지토리에 대한 액세스 권한을 부여합니다. 자세한 내용은 "조직 리포지토리에 대한 개인 액세스 권한 관리"을(를) 참조하세요.