제품 간 마이그레이션 정보

Enterprise Importer를 사용하면 Enterprise Server에서 Enterprise Cloud로 데이터를 마이그레이션하거나, .com에서 Enterprise Cloud의 다른 계정으로 데이터를 마이그레이션할 수 있습니다.

예를 들어, Enterprise Importer는 회사가 다음 작업을 수행할 수 있도록 도와줍니다.

• 엔터프라이즈를 GHE.com로 마이그레이션하여 데이터 보존 기능을 갖춘 Enterprise Cloud 채택
• .com에서 Enterprise Managed Users 또는 새 청구 모델과 같은 특정 기능을 .com에서 엔터프라이즈 간에 마이그레이션하여 채택
• Enterprise Server에서 Enterprise Cloud로 마이그레이션하여 간소화된 관리 및 새로운 기능의 이점 얻기

마이그레이션 원본이 .com의 계정인 경우 조직 간에 개별 리포지토리를 마이그레이션하거나 엔터프라이즈 간에 전체 조직을 마이그레이션할 수 있습니다. 마이그레이션 원본이 Enterprise Server인 경우 개별 리포지토리를 마이그레이션할 수 있습니다.

Enterprise Importer에서 마이그레이션하는 데이터는 마이그레이션의 원본과 리포지토리를 마이그레이션하는지, 조직을 마이그레이션하는지에 따라 달라집니다.

Enterprise Importer를 사용하기 전에 다음 고려 사항을 이해하세요.

• Enterprise Cloud를 이미 사용하는 경우: Enterprise 플랜에서는 한 번 Enterprise Cloud를 배포할 수 있도록 합니다.

  예를 들어, 이미 .com를 사용하고 Enterprise Server에서 GHE.com로 마이그레이션도 원할 경우, 둘 다에 대한 사용이 단일 플랜에서 보장되지 않습니다.

• Enterprise Managed Users로 마이그레이션하는 경우: 사용자 계정을 관리하려면 ID 공급자와 통합해야 합니다. 시작하기 전에 ID 공급자에 대한 지원 수준을 확인합니다. Enterprise Managed Users 정보을(를) 참조하세요.

• Enterprise Server에서 마이그레이션하는 경우: 에서는 특정 동작에 속도 제한을 적용합니다. Enterprise Server에서는 기본적으로 사용 안 함으로 설정되어 있습니다. REST API에 대한 트래픽률 제한을(를) 참조하세요.

• 데이터 보존 기능을 갖춘 Enterprise Cloud로 마이그레이션하는 경우: 특정 기능을 사용할 수 없고, 일부 기능에는 다른 구성 또는 추가 구성이 필요합니다. 데이터 보존 기능을 갖춘 Enterprise Cloud의 기능 개요을(를) 참조하세요.

Enterprise Server(GHES)에서 마이그레이션하려면 GHES 버전 3.4.1 이상이 있어야 합니다. 마이그레이션되는 데이터는 사용 중인 버전에 따라 달라집니다.

리포지토리당 다양한 크기 제한이 GHES 버전에 따라 적용됩니다.

현재 다음 데이터는 마이그레이션되지 않습니다.

• 감사 로그
• Code scanning 결과
• 커밋 상태 검사
• Dependabot 경고
• Dependabot 비밀
• 리포지토리 수준의 토론
• 문제 주석 및 끌어오기 요청 주석의 기록 편집
• 리포지토리 간의 포크 관계(포크 정보 참조)
• Actions 비밀, 변수, 환경, 자체 호스팅 실행기, 더 큰 실행기s 또는 워크플로 실행 기록
• 앱 및 앱 설치
• Git LFS -개체 및 큰 이진 파일(Git LFS 을 사용하는 리포지토리는 계속 지원됩니다. Enterprise Importer의 제한 사항을 참조하세요.)
• 병합되어 다시 지정된 끌어오기 요청에 대한 커밋의 링크
• Packages
• Projects(새로운 프로젝트 환경)
• 끌어오기 요청과 다른 리포지토리의 문제 간 참조(자동 링크된 참조 및 URL 참조)
• secret scanning 결과의 수정 상태
• 리포지토리는 사용자 계정이 소유합니다.
• 리포지토리 작업 피드
• 리포지토리 속성
• 리포지토리 별표
• 리포지토리 감시자
• 규칙 집합
• 태그 보호 규칙
• 사용자 프로필, SSH 키, 서명 키 또는 personal access tokens
• 웹후크 비밀
• Teams
• 리포지토리에 대한 사용자 또는 팀 액세스
• 끌어오기 요청에 대한 리포지토리 설정

분기 보호는 특정 분기 이름 또는 분기 이름 패턴에 지정된 규칙의 세트를 적용합니다. 자세한 내용은 보호된 분기 정보을(를) 참조하세요.

분기 보호는 항상 마이그레이션되지만 특정 규칙은 마이그레이션되지 않습니다. 다음 분기 보호 규칙은 마이그레이션되지 않습니다.

• 특정 행위자가 필요한 끌어오기 요청을 바이패스하도록 허용
• 최신 푸시의 승인 필요
• 병합 전 배포 성공 필요
• 분기 잠금
• 일치하는 분기를 만드는 푸시 제한
• 강제 푸시 허용

또한 다음과 같은 제한 사항이 적용됩니다.

• 분기 보호 규칙에서 선택적으로 "끌어오기 요청 검토를 해제할 수 있는 사람 제한"과 같이 규칙에서 제외된 사람, 팀 또는 앱을 지정할 수 있는 경우 예외는 마이그레이션되지 않습니다.
• "강제 푸시 허용" 규칙이 "강제 푸시할 수 있는 사용자 지정" 모드에서 사용하도록 설정된 경우 규칙은 마이그레이션되지 않습니다.

마이그레이션 원본이 .com의 계정인 경우 조직 간에 개별 리포지토리를 마이그레이션하거나 엔터프라이즈 간에 전체 조직을 마이그레이션할 수 있습니다.

조직을 마이그레이션하면 대상 엔터프라이즈 계정 내에 새 조직이 만들어집니다. 그런 다음, 다음 데이터가 새 조직으로 마이그레이션됩니다.

• Teams
• 리포지토리
• 리포지토리에 대한 팀 액세스
• 멤버 권한
• 조직 수준 웹후크(마이그레이션 후 다시 사용하도록 설정해야 함, 웹후크 사용 참조)
• 조직의 리포지토리에서 만들어진 새로운 리포지토리를 위한 기본 분기 이름

모든 리포지토리는 프라이빗 표시 여부로 마이그레이션됩니다. 리포지토리의 가시성을 퍼블릭 또는 내부로 설정하려는 경우 UI 또는 API를 사용하여 마이그레이션 후 이 작업을 수행할 수 있습니다.

팀 멤버십은 마이그레이션되지 않습니다. 마이그레이션 후에는 마이그레이션된 팀에 구성원을 추가해야 합니다. 자세한 내용은 제품 간 마이그레이션의 개요을(를) 참조하세요.

직접 또는 조직 마이그레이션의 일부로 리포지토리를 마이그레이션하는 경우 다음 데이터만 마이그레이션됩니다.

• Git 원본(커밋 기록 포함)
• 끌어오기 요청
• 문제
• 마일스톤
• Wiki(첨부 파일 제외)
• Actions 워크플로
• 커밋 주석
• 활성 웹후크(마이그레이션 후 다시 사용하도록 설정해야 함, 웹후크 사용 참조)
• 리포지토리 토픽
• 리포지토리 설정
  • 분기 보호(자세한 내용은 분기 보호 참조)
  • Pages 설정
  • 참조 자동 연결
  • 끌어오기 요청 설정
    • 자동으로 제목 분기 삭제
    • 자동 병합 허용
    • 병합 커밋 허용(커밋 메시지 설정이 기본 메시지로 다시 설정됨)
    • Squash 병합 허용(커밋 메시지 설정이 기본 메시지로 다시 설정됨)
    • 병합 다시 지정 허용
• 릴리스(리포지토리당 최대 10GB)
• 위의 데이터에 대한 사용자 기록
• 첨부 파일(파일 첨부 참조)

현재 다음 데이터는 마이그레이션되지 않습니다.

• Codespaces 비밀 * 감사 로그
• Code scanning 결과
• 커밋 상태 검사
• Dependabot 경고
• Dependabot 비밀
• 리포지토리 수준의 토론
• 문제 주석 및 끌어오기 요청 주석의 기록 편집
• 리포지토리 간의 포크 관계(포크 정보 참조)
• Actions 비밀, 변수, 환경, 자체 호스팅 실행기, 더 큰 실행기s 또는 워크플로 실행 기록
• 앱 및 앱 설치
• Git LFS -개체 및 큰 이진 파일(Git LFS 을 사용하는 리포지토리는 계속 지원됩니다. Enterprise Importer의 제한 사항을 참조하세요.)
• 병합되어 다시 지정된 끌어오기 요청에 대한 커밋의 링크
• Packages
• Projects(새로운 프로젝트 환경)
• 끌어오기 요청과 다른 리포지토리의 문제 간 참조(자동 링크된 참조 및 URL 참조)
• secret scanning 결과의 수정 상태
• 리포지토리는 사용자 계정이 소유합니다.
• 리포지토리 작업 피드
• 리포지토리 속성
• 리포지토리 별표
• 리포지토리 감시자
• 규칙 집합
• 태그 보호 규칙
• 사용자 프로필, SSH 키, 서명 키 또는 personal access tokens
• 웹후크 비밀
• 리포지토리에 대한 사용자 액세스

리포지토리를 직접 마이그레이션하는 경우 팀 및 팀 액세스 권한이 리포지토리로 마이그레이션되지 않습니다.

분기 보호는 특정 분기 이름 또는 분기 이름 패턴에 지정된 규칙의 세트를 적용합니다. 자세한 내용은 보호된 분기 정보을(를) 참조하세요.

분기 보호는 항상 마이그레이션되지만 특정 규칙은 마이그레이션되지 않습니다. 다음 분기 보호 규칙은 마이그레이션되지 않습니다.

• 특정 행위자가 필요한 끌어오기 요청을 바이패스하도록 허용
• 최신 푸시의 승인 필요
• 병합 전 배포 성공 필요
• 분기 잠금
• 일치하는 분기를 만드는 푸시 제한
• 강제 푸시 허용

또한 다음과 같은 제한 사항이 적용됩니다.

• 분기 보호 규칙에서 선택적으로 "끌어오기 요청 검토를 해제할 수 있는 사람 제한"과 같이 규칙에서 제외된 사람, 팀 또는 앱을 지정할 수 있는 경우 예외는 마이그레이션되지 않습니다.
• "강제 푸시 허용" 규칙이 "강제 푸시할 수 있는 사용자 지정" 모드에서 사용하도록 설정된 경우 규칙은 마이그레이션되지 않습니다.

Enterprise Importer에서 마이그레이션할 수 있는 항목에는 제한이 있습니다. 일부는 의 제한 사항으로 인해 발생하지만 다른 일부는 Enterprise Importer 자체의 제한 사항입니다.

• 단일 Git 커밋에 대한 2GB 크기 제한: Git 리포지토리의 단일 커밋은 2GB보다 클 수 없습니다. 커밋이 2GB보다 큰 경우 커밋을 각각 2GB 이하인 더 작은 커밋으로 분할해야 합니다.
• Git 참조에 대한 255바이트 제한: 일반적으로 "ref"라고 하는 단일 Git 참조는 255바이트보다 큰 이름을 가질 수 없습니다. 일반적으로 참고자료는 255자를 초과할 수 없지만 이모지와 같은 비 ASCII가 아닌 문자는 둘 이상의 바이트를 사용할 수 있습니다. Git 참고자료가 너무 크면 명확한 오류 메시지가 반환됩니다.
• 100MB 파일 크기 제한: 마이그레이션을 완료한 후에는 Git 리포지토리의 단일 파일이 100MB를 초과할 수 없습니다. 리포지토리를 마이그레이션하는 동안 이 제한은 400MB로 늘어납니다. 대용량 파일을 저장하려면 Git LFS를 사용해 보세요. 자세한 내용은 대형 파일 관리을(를) 참조하세요.

• Git 리포지토리의 40GB 크기 제한(공개 미리 보기): 이 제한은 소스 코드에만 적용됩니다. 리포지토리 보관이 한도를 초과하는지 확인하려면 git-sizer 도구를 사용하고 출력의 총 미확인 개체 크기를 검토합니다. git-sizer 도구는 또한 마이그레이션에 영향을 미칠 수 있는 큰 파일 보고서, 미확인 개체 크기, 커밋 크기 및 트리 수와 관련된 잠재적인 문제를 식별하는 데 도움이 됩니다.
• 메타데이터에 대한 40GB 제한(공개 미리 보기): Importer는 40GB 이상의 메타데이터를 사용하여 리포지토리를 마이그레이션할 수 없습니다. 메타데이터에는 문제, 끌어오기 요청, 릴리스 및 첨부 파일이 포함됩니다. 대부분의 경우 큰 메타데이터는 릴리스에 연결된 이진 자산으로 인해 발생합니다. migrate-repo 명령의 --skip-releases 플래그를 사용하여 마이그레이션에서 릴리스를 제외한 다음 마이그레이션 후에 릴리스를 수동으로 이동할 수 있습니다.
• 400 MB file size limit: When migrating a repository with Enterprise Importer, no single file in your Git repository can be larger than 400 MB. Consider using Git LFS for storing large files. For more information, see 대형 파일 관리.
• Git LFS objects not migrated: The Importer can migrate repositories that use Git LFS, but the LFS objects themselves will not be migrated. They can be pushed to your migration destination as a follow-up task after the migration is complete. For more information, see 리포지토리 복제.
• Follow-up tasks required: When migrating between products, certain settings are not migrated and must be reconfigured in the new repository. For a list of follow-up tasks you'll need to complete after each migration, see 제품 간 마이그레이션의 개요.
• Delayed code search functionality: Re-indexing the search index can take a few hours after a repository is migrated, and code searches may return unexpected results until re-indexing is complete.
• Rulesets configured for your organization can cause migrations to fail: For example, if you configured a rule that requires email addresses for commit authors to end with @monalisa.cat, and the repository you're migrating contains commits that don't comply with this rule, your migration will fail. For more information about rulesets, see 규칙 세트 정보.
• Mannequin content might not be searchable: Mannequins are placeholder users to which imported content (such as issues, pull requests, comments, etc.) is associated. When you search for content associated with a mannequin, such as assigned issues, the issues may not be found. Once a mannequin is reclaimed, the content should be found via the new owner. For more information, see Enterprise Importer에 대한 마네킹 회수.

제품 간에 마이그레이션하기 전에 마이그레이션 실행 방법을 계획해야 합니다. 데이터를 마이그레이션하기 전에 마이그레이션을 실행할 사용자를 선택해야 합니다. 마이그레이션의 원본과 대상 모두에 대해 필요한 액세스 권한을 해당 사용자에게 부여해야 합니다. 또한 먼저 평가판 마이그레이션을 실행하는 것이 좋습니다.

전체 마이그레이션 프로세스의 개요는 제품 간 마이그레이션의 개요을(를) 참조하세요.