{"meta":{"title":"GitLab에서 GitHub 마이그레이션 계획","intro":"타임라인, 마이그레이션할 데이터 및 조직 구조를 이해하여 마이그레이션을 계획합니다.","product":"마이그레이션","breadcrumbs":[{"href":"/ko/migrations","title":"마이그레이션"},{"href":"/ko/migrations/using-github-enterprise-importer","title":"GitHub Enterprise Importer"},{"href":"/ko/migrations/using-github-enterprise-importer/migrate-from-gitlab","title":"GitLab에서 마이그레이션"},{"href":"/ko/migrations/using-github-enterprise-importer/migrate-from-gitlab/plan-your-migration","title":"2. 마이그레이션 계획"}],"documentType":"article"},"body":"# GitLab에서 GitHub 마이그레이션 계획\n\n타임라인, 마이그레이션할 데이터 및 조직 구조를 이해하여 마이그레이션을 계획합니다.\n\n## 얼마나 마이그레이션해야 하는 양을 결정합니다.\n\n타임라인은 주로 접근 방식을 형성하기 때문에 먼저 타임라인을 파악합니다. 타임라인을 결정하는 첫 번째 단계는 마이그레이션해야 하는 항목의 인벤토리를 가져오는 것입니다.\n\n* 리포지토리 수(프로젝트)\n* 병합 요청 수\n\n> \\[!NOTE] 마이그레이션 타이밍은 주로 리포지토리의 병합 요청 수를 기반으로 합니다. 1,000개의 리포지토리를 마이그레이션하고 각 리포지토리에 평균 100개의 병합 요청이 있는 경우 마이그레이션이 매우 빠를 수 있습니다. 100개의 리포지토리만 마이그레이션하려고 하지만 리포지토리에 각각 평균 75,000개의 병합 요청이 있는 경우 마이그레이션 시간이 훨씬 더 오래 걸리고 더 많은 계획 및 테스트가 필요합니다.\n\n`inventory-report`에서 GL2GH extension of the GitHub CLI 명령을 사용하는 것을 추천합니다. 이 명령은 GitLab API에 연결하고 두 개의 CSV 파일을 만듭니다.\n`groups.csv` 는 GitLab 그룹을 나열하고 `projects.csv` 병합 요청 수를 포함하여 프로젝트를 나열합니다.\n\nCSV 파일을 생성하려면 다음 명령을 사용하여 GitLab 서버의 URL(예`GITLAB_SERVER_URL`: )과 `https://gitlab.com` 보고하려는 그룹으로 바꿉 `YOUR_GITLAB_GROUP` 니다. 액세스할 수 있는 모든 프로젝트를 보고하려면 생략 `--gitlab-group`합니다. 사용 가능한 모든 옵션에 대해 을 실행 `gh gl2gh inventory-report --help`합니다.\n\n```shell copy\ngh gl2gh inventory-report --gitlab-server-url GITLAB_SERVER_URL --gitlab-group YOUR_GITLAB_GROUP\n```\n\n마이그레이션해야 하는 리포지토리의 인벤토리를 가져와 원하는 타임라인과 비교할 때 인벤토리 데이터의 무게를 측정합니다.\n\n* 조직에서 더 높은 수준의 변화를 견딜 수 있는 경우, 모든 리포지토리를 한 번에 마이그레이션하여 며칠 안에 마이그레이션 작업을 완료할 수도 있습니다.\n* 동시에 마이그레이션할 수 없는 팀이 있는 경우 마이그레이션을 일괄 처리하고 팀의 타임라인에 맞게 스테이거하여 마이그레이션 노력을 확장할 수 있습니다.\n\n## 조직 구조 확인 GitHub\n\n다음으로, 여러분이 만들 조직 구조를 계획합니다 GitHub. GitLab 및 GitHub 기업의 작업을 구성하는 다양한 방법이 있습니다.\n\n* GitLab: 인스턴스 > 그룹 > 하위 그룹(최대 20 수준 깊이 중첩 가능) > 프로젝트(리포지토리)\n* GitHub: 엔터프라이즈 > 조직 > 리포지토리\n\n마이그레이션한 GitHub후에는 엔터프라이즈 계정 하나와 해당 엔터프라이즈가 소유한 여러 조직만 있어야 합니다. GitLab의 각 최상위 그룹은 일반적으로 단일 조직에 GitHub해당합니다. 만들 조직 수에 대한 지침은 [기업에서 작업을 구성하기 위한 모범 사례](/ko/enterprise-cloud@latest/admin/concepts/enterprise-best-practices/organize-work)을 참조하세요.\n\n> \\[!NOTE]\n> GitHub 은 GitLab의 중첩된 하위 그룹에 해당하지 않습니다. 각 하위 그룹에 대해 조직을 GitHub 만들지 않는 것이 좋습니다. 이로 인해 각 조직 내에서 그룹화되지 않은 리포지토리의 큰 목록이 발생할 수 있습니다. 대신 팀을 만들어 리포지토리 그룹에 대한 액세스를 관리할 수 있습니다.\n\n마이그레이션 작업을 일괄 처리로 중단하려는 경우 새 구조가 이를 확인하는 데 도움이 될 수 있습니다. GitLab에 둘 이상의 그룹이 있고 각 그룹의 리포지토리가 합리적으로 크기가 조정된 일괄 처리인 경우 그룹별로 일괄 처리를 고려합니다.\n\n1. 새 조직 구조를 결정합니다.\n2. 마이그레이션 작업을 더 작은 일괄 처리로 분할해야 하는지에 대한 여부를 결정합니다.\n3. 그렇다면, 마이그레이션을 중단하는 방법을 결정합니다.\n\n## 리포지토리 권한 구성\n\n권한은 GitLab과 GitHub 다르게 작동하므로 GitLab GitHub Enterprise Importer 에서 리포지토리 권한, 그룹 설정 또는 그룹 멤버 자격을 마이그레이션하지 않습니다.\n\nGitLab에서 멤버는 그룹, 하위 그룹 또는 프로젝트 수준에서 역할(예: 게스트, 리포터, 개발자, 유지 관리자 또는 소유자)을 부여받으며 이러한 역할은 계층 구조 아래로 상속됩니다. 이러한 역할은 직접 GitHub매핑되지 않으므로 마이그레이션 후 액세스를 다시 만들어야 합니다.\n\n마이그레이션된 리포지토리에 대한 GitHub액세스 권한을 사용자에게 부여하려면 팀을 만들고 각 팀에 관련 조직 및 리포지토리에 대한 적절한 수준의 액세스 권한을 부여하는 것이 좋습니다. 그런 다음 해당 팀에 사용자를 추가할 수 있습니다.\n[엔터프라이즈의 팀들](/ko/enterprise-cloud@latest/admin/concepts/enterprise-fundamentals/teams-in-an-enterprise)을(를) 참조하세요."}