Skip to main content

GitHub 제품 간 마이그레이션 정보

은(는) GitHub 제품 간에 마이그레이션 가능한 데이터를 알려줍니다.

GitHub 제품 간의 마이그레이션에 대해

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

예를 들어, GitHub Enterprise Importer는 회사가 다음 작업을 할 수 있도록 지원합니다.

  • enterprise를 GHE.com로 이전하여 데이터 보존 기능을 갖춘 GitHub Enterprise Cloud를 채택합니다.
  • GitHub.com에서 Enterprise Managed Users 또는 새 청구 모델과 같은 특정 기능을 enterprise 간에 마이그레이션하여 도입합니다.
  • GitHub Enterprise Server에서 GitHub Enterprise Cloud로 마이그레이션하면 관리가 간소화되고 새로운 기능의 이점을 얻을 수 있습니다.

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

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

대상 조직 또는 엔터프라이즈에 규칙 집합이 사용하도록 설정된 경우 마이그레이션된 리포지토리의 기록이 해당 규칙을 위반할 수 있습니다. 규칙 집합을 사용하지 않도록 설정하지 않고 마이그레이션을 허용하려면 해당하는 각 규칙 집합에 대한 바이패스 목록에 "리포지토리 마이그레이션"을 추가합니다. 이 바이패스는 마이그레이션 중에만 적용됩니다. 완료되면 규칙 집합이 모든 새 기여에 적용됩니다.

바이패스 구성:

  1. 각 엔터프라이즈 또는 조직 규칙 집합으로 이동합니다.
  2. "바이패스 목록" 섹션에서 바이패스 추가를 클릭합니다.
  3.        **리포지토리 마이그레이션을** 선택합니다.
    

자세한 내용은 조직 내 리포지토리에 대한 규칙 세트 만들기을(를) 참조하세요.

GitHub Enterprise Cloud로 마이그레이션을 하기 위한 고려 사항

GitHub Enterprise Importer를 사용하기 전에 다음 고려 사항을 숙지하시기 바랍니다.

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

    예를 들어, 이미 GitHub.com를 사용하고 GitHub Enterprise Server에서 GHE.com로 마이그레이션도 고려하고 있다면, 두 서비스 모두에 대한 사용이 단일 플랜에서 보장되지 않습니다.

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

  • GitHub Enterprise Server에서 마이그레이션하는 경우: GitHub에서는 특정 동작에는 속도 제한이 적용되며, GitHub Enterprise Server의 경우 기본적으로 비활성화되어 있습니다. REST API에 대한 트래픽률 제한을(를) 참조하세요.

  • 데이터 보존 기능을 갖춘 GitHub Enterprise Cloud로 마이그레이션하는 경우: 특정 기능은 사용할 수 없으며, 일부 기능을 사용하려면 다른 구성이나 추가 구성이 필요합니다. 데이터 상주 기능이 포함된 GitHub Enterprise Cloud 기능 개요.을(를) 참조하세요.

GitHub Enterprise Server에서 마이그레이션된 데이터

마이그레이션을 위해서는 GitHub Enterprise Server (GHES) 버전은 3.4.1 이상이 필요합니다. 마이그레이션되는 데이터는 사용 중인 버전에 따라 다릅니다.

항목GHES 3.4.1 이상GHES 3.5.0 이상
Git 원본(커밋 기록 포함)
끌어오기 요청
문제
마일스톤옥티콘 "check" aria-label="마이그레이션 가능" %}
Wikis옥티콘 "check" aria-label="마이그레이션 가능" %}
GitHub Actions 워크플로
커밋 설명옥티콘 "check" aria-label="마이그레이션 가능" %}
웹후크를 마이그레이션 후에 다시 사용하도록 설정해야 합니다. (웹후크 사용 참조)옥티콘 "check" aria-label="마이그레이션 가능" %}
분기 보호
GitHub Pages 설정
위의 데이터에 대한 사용자 기록
첨부 파일(파일 첨부 참조)
릴리스

압축 보관 파일은 GHES 버전에 따라 리포지토리별로 서로 다른 크기 제한이 적용될 수 있습니다.

제한GHES < 3.8.0GHES 3.8.x-3.11.xGHES 3.12.xGHES 3.13.0 이상
Git 원본2GiB10GiB20GiB40GiB(공개 미리 보기)
메타데이터2GiB10GiB20GiB40GiB(공개 미리 보기)

마이그레이션되지 않는 데이터

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

  • 감사 로그
  • Code scanning 결과
  • Codespaces 비밀
  • 커밋 상태 검사
  • Dependabot 경고
  • Dependabot 비밀
  • 리포지토리 수준에서 논의
  • 문제 주석 및 풀 리퀘스트 주석의 내역 편집
  • 리포지토리 간의 포크 관계( 포크에 대하여참조)
  • GitHub Actions 비밀, 변수, 환경, 자체 호스팅 실행기, 더 큰 실행기, 워크플로 아티팩트, 워크플로 실행 기록
  • GitHub 앱 및 GitHub 앱 설치
  • Git LFS 개체 및 큰 바이너리 파일(Git LFS 사용)을 사용하는 저장소는 계속 지원됩니다. GitHub Enterprise Importer의 제한 사항을 참조하세요.)
  • 병합 후 다시 지정된 풀 리퀘스트에 포함된 커밋 링크
  • 끌어오기 요청, 문제, 릴리스 및 주석 본문의 사용자, 팀 및 조직에 대한 언급(원래 언급된 사용자 이름은 유지됨)
  • GitHub Packages
  • Projects(새로운 프로젝트 환경)
  • 풀 리퀘스트와 다른 저장소의 이슈 간 참조 ( 자동 링크된 참조 및 URL참조)
  • secret scanning 결과의 수정 상태
  • 리포지토리는 사용자 계정에 귀속됩니다.
  • 리포지토리 작업 피드
  • 리포지토리 속성
  • 리포지토리 별표
  • 리포지토리 감시자
  • 규칙 집합
  • 하위 문제( 문제 개요 참조)
  • 태그 보호 규칙
  • 리포지토리에 대한 사용자 액세스
  • 사용자 프로필, SSH 키, 서명 키 또는 personal access tokens
  • 웹후크 비밀
  • 리포지토리에 대한 사용자 또는 팀 액세스
  • 풀 리퀘스트에 대한 리포지토리 설정

분기 보호

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

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

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

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

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

GitHub.com에서 마이그레이션된 데이터

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

조직의 마이그레이션된 데이터

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

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

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

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

참고

@octo-org/octo-team와(과) 같은 팀에 대한 참조는 조직 마이그레이션의 일부로 업데이트되지 않습니다. 이로 인해 CODEOWNERS 파일이 예상대로 작동하지 않는 등, 대상 조직에서 문제가 발생할 수 있습니다. 이러한 문제를 방지하고 해결하는 방법에 대한 자세한 내용은 GitHub Enterprise Importer를 사용하여 마이그레이션 문제 해결을(를) 참조하세요.

리포지토리의 마이그레이션된 데이터

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

  • Git 원본(커밋 기록 포함)
  • 끌어오기 요청
  • 문제
  • 마일스톤
  • Wiki(첨부 파일 제외)
  • GitHub Actions 워크플로
  • 커밋 설명
  • 액티브 웹후크를 마이그레이션 후에 다시 사용하도록 설정해야 합니다. (웹후크 사용 참조)
  • 리포지토리 토픽
  • 리포지토리 설정
    • 분기 보호(자세한 내용은 분기 보호 참조)
    • GitHub Pages 설정
    • 참조 자동 연결
    • 풀 리퀘스트 설정
      • 자동으로 제목 분기 삭제
      • 자동 병합 허용
      • 병합 커밋을 허용합니다(커밋 메시지 설정이 기본 메시지로 재설정됩니다).
      • 스쿼시 병합을 허용합니다(커밋 메시지 설정이 기본 메시지로 재설정됩니다).
      • 병합 다시 지정 허용
  • 릴리스(리포지토리당 최대 10GiB)
  • 위의 데이터에 대한 사용자 기록
  • 첨부 파일(파일 첨부 참조)

마이그레이션되지 않는 데이터

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

  • 감사 로그
  • Code scanning 결과
  • Codespaces 비밀
  • 커밋 상태 검사
  • Dependabot 경고
  • Dependabot 비밀
  • 리포지토리 수준에서 논의
  • 문제 주석 및 풀 리퀘스트 주석의 내역 편집
  • 리포지토리 간의 포크 관계( 포크에 대하여참조)
  • GitHub Actions 비밀, 변수, 환경, 자체 호스팅 실행기, 더 큰 실행기, 워크플로 아티팩트, 워크플로 실행 기록
  • GitHub 앱 및 GitHub 앱 설치
  • Git LFS 개체 및 큰 바이너리 파일(Git LFS 사용)을 사용하는 저장소는 계속 지원됩니다. GitHub Enterprise Importer의 제한 사항을 참조하세요.)
  • 병합 후 다시 지정된 풀 리퀘스트에 포함된 커밋 링크
  • 끌어오기 요청, 문제, 릴리스 및 주석 본문의 사용자, 팀 및 조직에 대한 언급(원래 언급된 사용자 이름은 유지됨)
  • GitHub Packages
  • Projects(새로운 프로젝트 환경)
  • 풀 리퀘스트와 다른 저장소의 이슈 간 참조 ( 자동 링크된 참조 및 URL참조)
  • secret scanning 결과의 수정 상태
  • 리포지토리는 사용자 계정에 귀속됩니다.
  • 리포지토리 작업 피드
  • 리포지토리 속성
  • 리포지토리 별표
  • 리포지토리 감시자
  • 규칙 집합
  • 하위 문제( 문제 개요 참조)
  • 태그 보호 규칙
  • 리포지토리에 대한 사용자 액세스
  • 사용자 프로필, SSH 키, 서명 키 또는 personal access tokens
  • 웹후크 비밀

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

분기 보호

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

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

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

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

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

마이그레이션된 데이터에 대한 제한 사항

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

GitHub의 제한 사항

  •         **단일 Git 커밋에 대한 2GiB 크기 제한:** Git 리포지토리의 단일 커밋은 2GiB보다 클 수 없습니다. 커밋이 2GiB보다 큰 경우 커밋을 각각 2GiB 이하인 더 작은 커밋으로 분할해야 합니다.
    
  •         **Git 참조에 대한 255바이트 제한:** 일반적으로 "ref"라고 하는 단일 [Git 참조](https://git-scm.com/book/en/v2/Git-Internals-Git-References)는 255바이트보다 큰 이름을 가질 수 없습니다. 일반적으로 참고자료는 255자를 초과할 수 없지만 이모지와 같은 비 [ASCII](https://en.wikipedia.org/wiki/ASCII)가 아닌 문자는 둘 이상의 바이트를 사용할 수 있습니다. Git 참고자료가 너무 크면 명확한 오류 메시지가 반환됩니다.
    
  •         **100MiB 파일 크기 제한:** 마이그레이션을 완료한 후에는 Git 리포지토리의 단일 파일이 100MiB를 초과할 수 없습니다. 리포지토리 마이그레이션 중에 이 제한은 400MiB로 증가합니다. 대용량 파일을 저장하려면 Git LFS를 사용해 보세요. 자세한 내용은 [AUTOTITLE](/repositories/working-with-files/managing-large-files)을(를) 참조하세요.
    

GitHub Enterprise Importer의 제한 사항

  • Git 리포지토리의 40GB 크기 제한(공개 미리 보기): 이 제한은 소스 코드에만 적용됩니다. 리포지토리 보관이 한도를 초과하는지 확인하려면 git-sizer 도구를 사용하고 출력의 총 미확인 개체 크기를 검토합니다. git-sizer 도구는 또한 마이그레이션에 영향을 미칠 수 있는 큰 파일 보고서, 미확인 개체 크기, 커밋 크기 및 트리 수와 관련된 잠재적인 문제를 식별하는 데 도움이 됩니다.
  •           **메타데이터에 대한 40GiB 제한(공개 미리 보기):** Importer는 메타데이터의 크기가 40GiB를 초과하는 리포지토리는 마이그레이션할 수 없습니다. 메타데이터에는 문제, 끌어오기 요청, 릴리스 및 첨부 파일이 포함됩니다. 대부분 큰 메타데이터는 릴리스에 연결된 이진 자산 때문에 발생합니다. `migrate-repo` 명령의 `--skip-releases` 플래그를 사용해 마이그레이션에서 릴리스를 제외한 뒤, 마이그레이션이 끝난 후 릴리스를 수동으로 옮길 수 있습니다.
    
  • 400MB 파일 크기 제한: GitHub Enterprise Importer를 사용하여 리포지토리를 마이그레이션할 때, Git 리포지토리의 단일 파일은 400MB를 초과할 수 없습니다. 대용량 파일을 저장하기 위해 Git LFS을(를) 사용하는 것을 고려합니다. 자세한 내용은 대형 파일 관리을(를) 참조하세요.
  • Git LFS 개체가 마이그레이션되지 않음: Importer은(는) Git LFS을(를) 사용하는 리포지토리를 마이그레이션할 수 있지만 LFS 개체 자체는 마이그레이션되지 않습니다. 마이그레이션이 완료된 후 후속작업으로 마이그레이션 대상에 푸시할 수 있습니다. 자세한 내용은 리포지토리 복제을(를) 참조하세요.
  • 후속작업 필요: GitHub 제품 간에 마이그레이션할 때 특정 설정은 마이그레이션되지 않으며 새 리포지토리에서 다시 구성해야 합니다. 각 마이그레이션 후에 완료해야 하는 후속작업 목록은 GitHub 제품 간 마이그레이션의 개요을(를) 참조하세요.
  • 지연된 코드 검색 기능: 리포지토리가 마이그레이션된 후 검색 인덱스를 다시 인덱싱하는 데 몇 시간이 걸릴 수 있으며, 코드 검색은 다시 인덱싱이 완료될 때까지 예기치 않은 결과를 반환할 수 있습니다.
  • 조직에 대해 구성된 규칙 집합으로 인해 마이그레이션 실패: 예를 들어 커밋 작성자의 이메일 주소가 @monalisa.cat(으)로 끝나야 하는 규칙을 구성하고 마이그레이션하려는 리포지토리에 이 규칙을 준수하지 않는 커밋이 포함되어 있으면 마이그레이션이 실패합니다. 규칙 집합에 대한 자세한 내용은 규칙 세트에 대한 정보을(를) 참조하세요.
  • 마네킹 콘텐츠가 검색되지 않을 수 있습니다. 마네킹은 가져온 콘텐츠(예: 이슈, 끌어오기 요청, 메모 등)가 연결된 자리 표시자 사용자입니다. 할당된 이슈와 같이 마네킹과 연결된 콘텐츠를 검색하는 경우 이슈를 찾지 못할 수 있습니다. 마네킹이 회수되면 새 소유자를 통해 콘텐츠를 찾아야 합니다. 자세한 내용은 GitHub Enterprise Importer용 마네킹 회수하기을(를) 참조하세요.

시작

GitHub 제품 간 마이그레이션을 진행하기 전에, 마이그레이션 실행 방법을 미리 계획해야 합니다. 데이터 마이그레이션을 진행하기 전에, 마이그레이션을 수행할 사용자를 선택해야 합니다. 마이그레이션의 원본과 대상 모두에 대해 해당 사용자에게 필요한 접근 권한을 부여해야 합니다. 또한 먼저 평가판 마이그레이션을 실행할 것을 권장합니다.

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