가져오기 기간 예측
전제 조건
- 권한 및 역할
- 사용자 기여 매핑을 위한 계정
알려진 문제
GitHub 리포지토리를 GitLab으로 가져오기
리포지토리 미러링 및 파이프라인 상태 공유
자가 관리 인스턴스에서 가져오기 속도 개선
- Sidekiq 작업자 수 늘리기
- GitHub Enterprise Cloud OAuth 앱을 사용하여 GitHub OAuth 활성화
가져온 데이터
- 브랜치 보호 규칙 및 프로젝트 설정
- 협력자 (회원)
내부 네트워크에서 GitHub Enterprise 가져오기
- 샘플 리버스 프록시 구성

GitHub에서 GitLab로 프로젝트 가져오기

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

GitLab 15.8에서 도입됨, GitLab은 더 이상 존재하지 않는 네임스페이스나 그룹을 자동으로 생성하지 않습니다. GitLab은 네임스페이스나 그룹 이름이 사용할 수 없을 경우 사용자의 개인 네임스페이스를 자동으로 사용하지도 않습니다.

GitLab 15.10에서 도입됨, 이제 GitLab에서 머지하기 전에 풀 요청을 요구함 - 지정된 행위자가 필수 풀 요청을 우회할 수 있도록 허용 브랜치 보호 규칙을 성공적으로 가져오기 위해 부모 그룹에 사용자를 추가할 필요가 없습니다.

GitLab 17.2에서 도입된 일부 가져온 항목에 대한 Imported 배지.

GitHub의 GitHub.com 또는 GitHub Enterprise에서 GitHub 프로젝트를 가져올 수 있습니다. 프로젝트를 가져오는 것은 GitHub에서 GitLab으로 그룹이나 조직의 유형을 마이그레이션하거나 가져오지 않습니다.

GitHub에서 GitLab.com으로 가져오는 것은 현재 사용할 수 없습니다. 해결 예상 시간은 없습니다. 자세한 내용은 지원팀에 연락해 주세요.

가져온 문제, 병합 요청, 댓글 및 이벤트는 GitLab에서 Imported 배지가 있습니다.

네임스페이스는 GitLab의 사용자 또는 그룹으로, 예를 들어 gitlab.com/sidney-jones 또는 gitlab.com/customer-success와 같습니다.

GitLab UI를 사용하여 GitHub 가져오는 도구는 항상 github.com 도메인에서 가져옵니다. 자체 호스트된 GitHub Enterprise Server 도메인에서 가져오는 경우 GitLab Import API GitHub 엔드포인트를 사용하세요.

가져오기 전에 대상 네임스페이스와 대상 리포지토리 이름을 변경할 수 있습니다.

가져오기 프로세스에 대한 개요는 GitHub에서 GitLab로 마이그레이션하는 방법 포함을 참조하세요.

가져오기 기간 예측

GitHub에서의 모든 가져오기는 다르며, 이는 수행하는 가져오기 기간에 영향을 미칩니다. 하지만 우리의 테스트에서 우리는 https://github.com/kubernetes/kubernetes를 76시간에 가져왔습니다. 테스트 당시 해당 프로젝트는 다음으로 구성되었습니다:

80,000개의 풀 요청.
45,000개의 문제.
대략 150만 개의 댓글.

전제 조건

GitHub에서 프로젝트를 가져오려면
GitHub 가져오기 소스를 활성화해야 합니다. 해당 가져오기 소스가 활성화되어 있지 않은 경우, GitLab 관리자에게 활성화해 달라고 요청하세요. GitLab.com에서는 기본적으로 GitHub 가져오기 소스가 활성화되어 있습니다.

권한 및 역할

GitLab 16.0에서 도입된 Maintainer 역할의 요구 사항이 GitLab 15.11.1 및 GitLab 15.10.5에 이식되었습니다.

GitHub 가져오기 도구를 사용하려면 다음이 필요합니다:

가져오려는 GitHub 프로젝트에 대한 접근 권한.
가져올 목적지 GitLab 그룹에서 최소한 Maintainer 역할.

또한, GitHub 리포지토리가 속한 조직은 GitLab 인스턴스에 대한 타사 애플리케이션 접근 정책 제약 조건을 부과하지 않아야 합니다.

사용자 기여 매핑을 위한 계정

GitHub와 GitLab 간의 사용자 기여 매핑이 작동하려면:

저장소의 각 GitHub 작성자 및 수임자는 공개 이메일 주소가 필요합니다.
GitHub 사용자의 이메일 주소는 GitLab 이메일 주소와 일치해야 합니다.
사용자의 GitHub 이메일 주소가 GitLab에서 보조 이메일 주소로 설정된 경우, 이를 확인해야 합니다.

GitHub Enterprise는 공개 이메일 주소가 필요하지 않으므로, 기존 계정에 이메일 주소를 추가해야 할 수 있습니다.

위 요구 사항이 충족되지 않으면, 가져오는 도구는 특정 사용자의 기여를 매핑할 수 없습니다. 이 경우:

프로젝트 작성자가 문제 및 병합 요청의 작성자 및 수임자로 설정됩니다. 프로젝트 작성자는 일반적으로 가져오기 프로세스를 시작한 사용자입니다. 기여 중 일부는 풀 요청, 문제, 노트와 같은 설명이나 메모가 포함되어 있으며, 가져오는 도구는 기여를 원래 생성한 사람의 세부 정보로 텍스트를 수정합니다.
GitHub에서 풀 요청에 추가된 리뷰어와 승인은 가져올 수 없습니다. 이 경우, 가져오는 도구는 존재하지 않는 사용자가 리뷰어 및 승인자로 추가되었다는 내용을 설명하는 댓글을 생성합니다. 그러나 실제 리뷰어 상태와 승인은 GitLab의 병합 요청에 적용되지 않습니다.

알려진 문제

2017년 이전에 생성된 GitHub 풀 요청 댓글(기타 GitLab에서는 diff notes로 알려짐)은 별도의 스레드로 가져옵니다. 이는 GitHub API의 제한으로 인해 2017년 이전의 댓글에 대한 in_reply_to_id가 포함되지 않기 때문입니다.
알려진 문제로 인해, GitHub Enterprise Server 인스턴스의 저장소에서 Markdown 첨부 파일이 가져오지 않습니다.
알려진 문제로 인해, GitHub 자동 병합을 사용한 프로젝트를 가져올 때, GitLab의 가져온 프로젝트는 GitHub의 내부 GPG 키로 서명된 커밋이 있는 경우 “검증되지 않음”으로 레이블이 붙은 병합 커밋을 가질 수 있습니다.
GitLab은 2023-05-09 이전에 비공개 저장소에 업로드된 GitHub Markdown 이미지 첨부 파일을 가져올 수 없습니다. 이 문제가 발생하고 해결을 도와주고 샘플 저장소를 제공할 의사가 있으신 경우, 문제 424046에 댓글을 추가해주세요. 저희가 연락드리겠습니다.
GitLab 전용 참조로, GitLab은 이슈에 대해 # 문자를, 병합 요청에 대해 ! 문자를 사용합니다. 그러나 GitHub은 이슈와 풀 요청 모두에 대해 # 문자만 사용합니다. 가져오는 과정에서:
- 댓글 노트에서는 GitLab이 이슈에 대한 링크만 생성합니다. 왜냐하면 GitLab은 참조가 이슈 또는 병합 요청을 가리키는지 결정할 수 없기 때문입니다.
- 이슈 또는 병합 요청 설명에서는 GitLab이 어떤 참조의 링크도 생성하지 않습니다. 왜냐하면 가져온 대응물이 아직 목적지에서 생성되지 않았을 수 있기 때문입니다.

GitHub 리포지토리를 GitLab으로 가져오기

시작하기 전에, 매핑하려는 모든 GitHub 사용자가 GitLab 사용자와 연결되도록 해당 사용자의 GitLab 이메일 주소가 그들의 공개 이메일 주소 와 일치하는지 확인하세요.

GitHub 사용자의 공개 이메일 주소가 어떤 GitLab 사용자 이메일 주소와 일치하지 않으면, 사용자의 활동은 가져오기 작업을 수행하는 사용자 계정에 연결됩니다.

GitHub 리포지토리를 가져오는 방법은 다음과 같습니다:

GitHub OAuth 사용하기
GitHub 개인 액세스 토큰 사용하기
API 사용하기

github.com에서 가져오는 경우, 어떤 방법을 사용해도 가져올 수 있습니다. 자체 호스팅된 GitHub Enterprise Server 고객은 API를 사용해야 합니다.

GitHub OAuth 사용하기

GitLab.com 또는 GitHub OAuth가 구성된 자체 관리형 GitLab으로 가져오는 경우, GitHub OAuth를 사용하여 리포지토리를 가져올 수 있습니다.

이 방법은 개인 액세스 토큰 (PAT)를 사용하는 것보다 장점이 있습니다. 왜냐하면 백엔드가 적절한 권한을 가진 액세스 토큰으로 교환하기 때문입니다.

왼쪽 사이드바에서 상단의 Create new () 및 New project/repository를 선택합니다.
Import project를 선택한 후 GitHub를 선택합니다.
Authorize with GitHub를 선택합니다.
가져올 리포지토리 선택하기로 진행합니다.

이 단계를 수행한 후 다른 방법을 사용하여 가져오려면, GitLab 계정에서 로그아웃하고 다시 로그인하세요.

GitHub 개인 액세스 토큰 사용하기

GitHub 개인 액세스 토큰을 사용하여 GitHub 리포지토리를 가져오려면:

GitHub 개인 액세스 토큰을 생성합니다. 클래식 개인 액세스 토큰만 지원됩니다.
1. https://github.com/settings/tokens/new로 이동합니다.
2. Note 필드에 토큰 설명을 입력합니다.
3. repo 범위를 선택합니다.
4. 선택사항. 협업자 가져오기 또는 프로젝트에 Git LFS 파일이 있는 경우, read:org 범위를 선택합니다.
5. Generate token을 선택합니다.
GitLab 왼쪽 사이드바에서 상단의 Create new () 및 New project/repository를 선택합니다.
Import project를 선택한 후 GitHub를 선택합니다.
Authorize with GitHub를 선택합니다.
Personal access token 필드에 GitHub 개인 액세스 토큰을 붙여넣습니다.
Authenticate를 선택합니다.
가져올 리포지토리 선택하기로 진행합니다.

이 단계를 수행한 후 다른 토큰을 사용하여 가져오려면, GitLab 계정에서 로그아웃하고 다시 로그인하거나, GitHub에서 이전 토큰을 취소하세요.

API 사용하기

GitLab REST API를 사용하여 GitHub 리포지토리를 가져올 수 있습니다. 이 방법은 GitLab UI를 사용하는 것보다 몇 가지 장점이 있습니다:

소유하지 않는 공개 GitHub 리포지토리를 가져오는 데 사용할 수 있습니다.
자체 호스팅된 GitHub Enterprise Server에서 가져오는 데 사용할 수 있습니다.
UI에서 사용할 수 없는 timeout_strategy 옵션을 설정하는 데 사용할 수 있습니다.

REST API는 GitLab 개인 액세스 토큰으로 인증하는 데 제한됩니다.

GitLab REST API를 사용하여 GitHub 리포지토리를 가져오려면:

GitHub 개인 액세스 토큰을 생성합니다. 클래식 개인 액세스 토큰만 지원됩니다.
1. https://github.com/settings/tokens/new로 이동합니다.
2. Note 필드에 토큰 설명을 입력합니다.
3. repo 범위를 선택합니다.
4. 선택사항. 협업자 가져오기 또는 프로젝트에 Git LFS 파일이 있는 경우, read:org 범위를 선택합니다.
5. Generate token을 선택합니다.
GitLab REST API를 사용하여 GitHub 리포지토리를 가져옵니다.

리포지토리 목록 필터링

GitLab 16.0에 도입됨.

GitHub 리포지토리에 대한 액세스를 승인한 후, GitLab은 가져오기 페이지로 리디렉션하고
당신의 GitHub 리포지토리가 나열됩니다.

다음 탭 중 하나를 사용하여 리포지토리 목록을 필터링하세요:

소유자 (기본값): 당신이 소유한 리포지토리로 목록을 필터링합니다.
협업: 당신이 기여한 리포지토리로 목록을 필터링합니다.
조직: 당신이 소속된 조직에 속한 리포지토리로 목록을 필터링합니다.

조직 탭이 선택된 경우, 드롭다운 목록에서 사용 가능한 GitHub 조직을 선택하여 검색 범위를 추가로 좁힐 수 있습니다.

가져올 추가 항목 선택

GitLab 15.5에 도입됨.

추가 항목으로서 협업자를 가져오는 기능은 GitLab 16.0에 도입됨.

기능 플래그 github_import_extended_events는 GitLab 16.8에 도입됨. 기본적으로 비활성화됨. 이 플래그는 가져오기 성능을 개선하지만 문제 및 풀 요청 이벤트 가져오기 옵션을 제거합니다.

기능 플래그 github_import_extended_events는 GitLab 16.9에서 GitLab.com 및 셀프 관리에 대해 활성화됨.

개선된 가져오기 성능이 GitLab 16.11에서 일반적으로 사용 가능하게 됨. 기능 플래그 github_import_extended_events가 제거됨.

가져오기를 최대한 빠르게 하기 위해, 기본적으로 GitHub에서 다음 항목은 가져오지 않습니다:

약 30,000개 이상의 댓글은 GitHub API의 제한으로 인해 가져오지 않습니다.
리포지토리 댓글, 릴리스 게시물, 문제 설명 및 풀 요청 설명에서의 Markdown 첨부 파일. 여기에는
이미지, 텍스트 또는 바이너리 첨부 파일이 포함될 수 있습니다. 가져오지 않으면, GitHub에서 첨부 파일을 제거한 후
첨부 파일에 대한 Markdown 링크가 중단됩니다.

이 항목들을 가져오도록 선택할 수 있지만, 이는 가져오기 시간을 크게 늘릴 수 있습니다. 이러한 항목을 가져오기 위해 UI에서 적절한 필드를 선택하세요:

대체 댓글 가져오기 방법 사용. 모든 문제와 풀 요청에서 약 30,000개 이상의 댓글이 포함된 GitHub 프로젝트를 가져온다면,
GitHub API의 제한으로 인해 이 방법을 활성화해야 합니다.
Markdown 첨부 파일 가져오기.
협업자 가져오기 (기본적으로 선택됨). 선택 상태로 두면 신규 사용자가 그룹 또는 네임스페이스에서 자리를 차지하게 되고,
프로젝트 소유자만큼 높은 권한이 부여될 수 있습니다. 직접 협업자만 가져옵니다.
외부 협업자는 절대 가져오지 않습니다.

가져올 리포지토리 선택

보류 중이거나 활성 가져오기를 취소하는 기능은 GitLab 15.7에 도입됨.

프로젝트를 재가져오는 기능은 GitLab 15.9에 도입됨.

기본적으로 제안된 리포지토리 네임스페이스는 GitHub에 존재하는 이름과 일치하지만,
당신의 권한에 따라 이 이름들을 가져오기 전에 편집할 수 있습니다.

가져올 리포지토리를 선택하려면, 리포지토리 옆의 가져오기 또는 모든 리포지토리 가져오기를 선택하세요.

추가로, 이름으로 프로젝트를 필터링할 수 있습니다. 필터가 적용되면, 모든 리포지토리 가져오기는
일치하는 리포지토리만 가져옵니다.

상태 열은 각 리포지토리의 가져오기 상태를 보여줍니다. 페이지를 열어 두고 실시간으로 업데이트를 지켜보거나 나중에 다시 돌아올 수 있습니다.

보류 중이거나 진행 중인 가져기를 취소하려면, 가져온 프로젝트 옆의 취소를 선택하세요.
가져오기가 이미 시작된 경우, 가져온 파일은 유지됩니다.

가져온 후 GitLab URL에서 리포지토리를 열려면, 해당 GitLab 경로를 선택하세요.

완료된 가져오는 재가져오기를 선택하고 새 이름을 지정하여 재가져올 수 있습니다.
이렇게 하면 원본 프로젝트의 새로운 복사본이 생성됩니다.

가져오기 상태 확인

GitLab 16.1에서 소개된 가져오기가 부분적으로 완료된 세부사항과 가져오기에 실패한 엔터티 목록입니다.

가져오기가 완료된 후, 가져오기는 세 가지 상태 중 하나에 있을 수 있습니다:

완료: GitLab이 모든 리포지토리 엔터티를 가져왔습니다.
부분적으로 완료됨: GitLab이 일부 리포지토리 엔터티를 가져오는 데 실패하였습니다.
실패: GitLab이 치명적인 오류 발생 후 가져오기를 중단하였습니다.

세부정보를 확장하여 가져오기에 실패한 리포지토리 엔터티 목록을 확인하세요.

리포지토리 미러링 및 파이프라인 상태 공유

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

귀하의 GitLab 등급에 따라, 리포지토리 미러링을 설정하여 가져온 리포지토리와 GitHub 복사본을 동기화할 수 있습니다.

또한, GitLab을 구성하여 파이프라인 상태 업데이트를 GitHub에 다시 보내도록 할 수 있습니다. GitHub 프로젝트 통합으로 가능합니다.

CI/CD for external repository를 사용하여 프로젝트를 가져오는 경우, 위의 두 가지가 자동으로 구성됩니다.

미러링은 GitHub 프로젝트의 새로운 요청이나 업데이트된 요청을 동기화하지 않습니다.

자가 관리 인스턴스에서 가져오기 속도 개선

이 단계에서는 GitLab 서버에 대한 관리자 액세스가 필요합니다.

Sidekiq 작업자 수 늘리기

대규모 프로젝트의 경우 모든 데이터를 가져오는 데 시간이 걸릴 수 있습니다. 필요한 시간을 줄이기 위해, 다음 큐를 처리하는 Sidekiq 작업자 수를 늘릴 수 있습니다:

github_importer
github_importer_advance_stage

최적의 경험을 위해, 적어도 4개의 Sidekiq 프로세스(각각 CPU 코어 수와 동일한 수의 스레드를 실행)가 이 큐만 처리하도록 설정하는 것이 좋습니다. 이 프로세스들은 별도의 서버에서 실행되는 것이 좋습니다. 8코어의 4서버로는 최대 32개의 객체(예: 이슈)를 병렬로 가져올 수 있습니다.

리포지토리를 복제하는 데 소비되는 시간을 줄이는 방법은 네트워크 처리량, CPU 용량 및 디스크 성능(예: 고성능 SSD 사용)을 증가시키는 것입니다. 리포지토리를 저장하는 디스크의 성능을 향상시킵니다. Sidekiq 작업자를 늘리는 것은 리포지토리 복제에 소요되는 시간을 줄이지 않습니다.

GitHub Enterprise Cloud OAuth 앱을 사용하여 GitHub OAuth 활성화

GitHub Enterprise Cloud 조직에 속한 경우 자가 관리 GitLab 인스턴스를 구성하여 더 높은 GitHub API 비율 제한을 얻을 수 있습니다.

GitHub API 요청은 보통 시간당 5,000개의 요청 비율 제한이 있습니다. 아래 단계를 사용하면 시간당 15,000개의 요청 비율 제한을 얻어 전반적인 가져오기 시간을 단축할 수 있습니다.

전제 조건:

GitHub Enterprise Cloud 조직에 대한 액세스 권한이 있습니다.
GitLab은 GitHub OAuth를 활성화하도록 구성되어 있습니다.

더 높은 비율 제한을 활성화하려면:

GitHub에서 OAuth 앱을 생성하세요. OAuth 앱 소유자가 개인 GitHub 계정이 아닌 Enterprise Cloud Organization임을 확인하세요.
GitHub OAuth를 사용하여 프로젝트 가져오기를 수행하세요.
선택 사항. 기본적으로 모든 구성된 OAuth 공급자에 대해 로그인 기능이 활성화되어 있습니다. 가져오기를 위해 GitHub OAuth를 활성화하고 싶지만 사용자가 GitHub로 GitLab 인스턴스에 로그인하는 것을 막고 싶다면, GitHub로 로그인을 비활성화할 수 있습니다.

가져온 데이터

프로젝트의 다음 항목이 가져옵니다:

저장소 설명.
Git 저장소 데이터.
모든 프로젝트 브랜치.
열린 풀 요청과 관련된 프로젝트의 포크의 모든 브랜치, 그러나 닫힌 풀 요청은 제외됩니다. 포크의 브랜스는 GH-SHA-username/pull-request-number/fork-name/branch와 유사한 명명 규칙으로 가져옵니다.
브랜치 보호 규칙. 소개됨 GitLab 15.4에서.
협력자(멤버). 소개됨 GitLab 15.10에서. GitLab 16.0부터 추가 항목으로 가져올 수 있음.
이슈.
풀 요청.
위키 페이지.
마일스톤.
레이블.
릴리스 노트 콘텐츠.
첨부 파일:
- 릴리스 노트. 소개됨 GitLab 15.4에서.
- 댓글. 소개됨 GitLab 15.5에서.
- 이슈 설명. 소개됨 GitLab 15.5에서.
- 풀 요청 설명. 소개됨 GitLab 15.5에서.
모든 첨부 파일 가져오는 것은 기본적으로 비활성화되어 있습니다. github_importer_attachments_import 기능 플래그. GitLab 15.5부터는 추가 항목으로 가져올 수 있음. 기능 플래그는 제거되었습니다.
풀 요청 검토 댓글.
정기 이슈 및 풀 요청 댓글.
Git 대용량 파일 저장소 (LFS) 개체.
풀 요청 리뷰.
풀 요청 할당 리뷰어. 소개됨 GitLab 15.6에서.
풀 요청 “병합된 사람” 정보.
논의에서의 댓글에 대한 풀 요청 댓글 답장. 소개됨 GitLab 14.5에서.
풀 요청 검토 댓글 제안. 소개됨 GitLab 14.7에서.
이슈 이벤트 및 풀 요청 이벤트. 소개됨 GitLab 15.4에서 github_importer_issue_events_import 기능 플래그가 기본적으로 비활성화되어 있습니다. GitLab 15.5부터는 추가 항목으로 가져올 수 있음. 기능 플래그는 제거되었습니다.

풀 요청 및 이슈에 대한 참조는 보존됩니다. 각 가져온 저장소는 가시성 수준을 유지하며, 가시성 수준이 제한되지 않는 한, 이 경우 기본 프로젝트 가시성으로 설정됩니다.

브랜치 보호 규칙 및 프로젝트 설정

가져올 때, 지원되는 GitHub 브랜치 보호 규칙은 다음에 매핑됩니다:

GitLab 브랜치 보호 규칙.
프로젝트 전체 GitLab 설정.

GitHub 규칙	GitLab 규칙	도입됨
병합 전에 대화 해결 요구 프로젝트의 기본 브랜치	모든 스레드는 해결되어야 합니다 프로젝트 설정	GitLab 15.5
병합 전에 풀 요청 요구	아무도 옵션이 있는 푸시 및 병합 허용 목록의 브랜치 보호 설정	GitLab 15.5
프로젝트의 기본 브랜치에 서명된 커밋 요구	서명되지 않은 커밋 거부 GitLab 푸시 규칙	GitLab 15.5
강제 푸시 허용 - 모든 사람	강제 푸시 허용 브랜치 보호 설정	GitLab 15.6
병합 전에 풀 요청 요구 - 코드 소유자의 검토 요구	코드 소유자의 승인 요구 브랜치 보호 설정	GitLab 15.6
병합 전에 풀 요청 요구 - 지정된 행위자가 필수 풀 요청 우회 허용	푸시 및 병합 허용 목록의 사용자 목록 브랜치 보호 설정. Premium 구독이 없는 경우, 푸시 및 병합을 허용하는 사용자의 목록은 역할로 제한됩니다.	GitLab 15.8

GitHub 규칙 병합 전에 상태 확인 요구를 외부 상태 확인로 매핑하는 것은 문제 370948에서 고려되었습니다.

하지만, 기술적인 어려움으로 인해 이 규칙은 GitLab에 프로젝트를 가져올 때 가져오지 않습니다.

여전히 외부 상태 확인을 수동으로 생성할 수 있습니다.

협력자 (회원)

GitLab 15.10에서 소개됨.

이 GitHub 협력자 역할은 다음 GitLab 회원 역할과 매핑됩니다:

GitHub 역할	매핑된 GitLab 역할
읽기	게스트
분류	리포터
쓰기	개발자
유지 관리	유지 관리
관리자	소유자

GitHub Enterprise Cloud에는 사용자 정의 리포지토리 역할이 있습니다. 이 역할은 지원되지 않으며 부분적으로 완료된 가져오기를 유발합니다.

GitHub 협력자를 가져오려면 GitHub 프로젝트에서 최소한 쓰기 역할을 가져야 합니다. 그렇지 않으면 협력자 가져오기가 건너뜁니다.

내부 네트워크에서 GitHub Enterprise 가져오기

GitHub Enterprise 인스턴스가 인터넷에 접근할 수 없는 내부 네트워크에 있는 경우, GitLab.com이 인스턴스에 접근할 수 있도록 리버스 프록시를 사용할 수 있습니다.

프록시는 다음과 같아야 합니다:

GitHub Enterprise 인스턴스에 요청을 전달합니다.
다음의 모든 내부 호스트 이름을 공개 프록시 호스트 이름으로 변환합니다:
- API 응답 본문.
- API 응답 Link 헤더.

GitHub API는 페이지네이션을 위해 Link 헤더를 사용합니다.

프록시를 구성한 후, API 요청을 만들어 테스트합니다. 아래는 API를 테스트하기 위한 명령어 예시입니다:

curl --header "Authorization: Bearer <YOUR-TOKEN>" "https://{PROXY_HOSTNAME}/user"

### 응답 본문의 URL은 프록시 호스트 이름을 사용해야 합니다

{
  "login": "example_username",
  "id": 1,
  "url": "https://{PROXY_HOSTNAME}/users/example_username",
  "html_url": "https://{PROXY_HOSTNAME}/example_username",
  "followers_url": "https://{PROXY_HOSTNAME}/api/v3/users/example_username/followers",
  ...
  "created_at": "2014-02-11T17:03:25Z",
  "updated_at": "2022-10-18T14:36:27Z"
}

curl --head --header "Authorization: Bearer <YOUR-TOKEN>" "https://{PROXY_DOMAIN}/api/v3/repos/{repository_path}/pulls?states=all&sort=created&direction=asc"

### Link 헤더는 프록시 호스트 이름을 사용해야 합니다

HTTP/1.1 200 OK
Date: Tue, 18 Oct 2022 21:42:55 GMT
Server: GitHub.com
Content-Type: application/json; charset=utf-8
Cache-Control: private, max-age=60, s-maxage=60
...
X-OAuth-Scopes: repo
X-Accepted-OAuth-Scopes:
github-authentication-token-expiration: 2022-11-22 18:13:46 UTC
X-GitHub-Media-Type: github.v3; format=json
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4997
X-RateLimit-Reset: 1666132381
X-RateLimit-Used: 3
X-RateLimit-Resource: core
Link: <https://{PROXY_DOMAIN}/api/v3/repositories/1/pulls?page=2>; rel="next", <https://{PROXY_DOMAIN}/api/v3/repositories/1/pulls?page=11>; rel="last"

프록시를 사용하여 리포지토리를 클론할 때 오류가 발생하지 않는지도 테스트합니다:

git clone -c http.extraHeader="Authorization: basic <base64 encode YOUR-TOKEN>" --mirror https://{PROXY_DOMAIN}/{REPOSITORY_PATH}.git

샘플 리버스 프록시 구성

다음 구성은 Apache HTTP 서버를 리버스 프록시로 설정하는 방법의 예입니다.

경고:
단순화를 위해 클라이언트와 프록시 간의 연결을 암호화하는 구성은 포함되어 있지 않습니다. 그러나 보안상의 이유로 이 구성을 포함해야 합니다. 샘플 Apache TLS/SSL 구성을 참조하세요.

# 필요한 모듈
LoadModule filter_module lib/httpd/modules/mod_filter.so
LoadModule reflector_module lib/httpd/modules/mod_reflector.so
LoadModule substitute_module lib/httpd/modules/mod_substitute.so
LoadModule deflate_module lib/httpd/modules/mod_deflate.so
LoadModule headers_module lib/httpd/modules/mod_headers.so
LoadModule proxy_module lib/httpd/modules/mod_proxy.so
LoadModule proxy_connect_module lib/httpd/modules/mod_proxy_connect.so
LoadModule proxy_http_module lib/httpd/modules/mod_proxy_http.so
LoadModule ssl_module lib/httpd/modules/mod_ssl.so

<VirtualHost GITHUB_ENTERPRISE_HOSTNAME:80>
  ServerName GITHUB_ENTERPRISE_HOSTNAME

  # SSL 지원을 통한 리버스 프록시 구성 활성화
  SSLProxyEngine On
  ProxyPass "/" "https://GITHUB_ENTERPRISE_HOSTNAME/"
  ProxyPassReverse "/" "https://GITHUB_ENTERPRISE_HOSTNAME/"

  # 로컬 GitHub Enterprise URL의 발생을 프록시 URL로 대체
  # GitHub Enterprise는 응답을 압축하므로 INFLATE 및 DEFLATE 필터를 사용하여
  # 응답을 다시 압축하고 압축 해제해야 합니다.
  AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE application/json
  Substitute "s|https://GITHUB_ENTERPRISE_HOSTNAME|https://PROXY_HOSTNAME|ni"
  SubstituteMaxLineLength 50M

  # GitHub API는 API 페이지 매김을 위해 응답 헤더 "Link"를 사용합니다.
  # 예를 들어:
  #   <https://example.com/api/v3/repositories/1/issues?page=2>; rel="next", <https://example.com/api/v3/repositories/1/issues?page=3>; rel="last"
  # 아래 지시는 응답 헤더 Link가 존재할 경우 GitHub Enterprise URL의 모든 발생을 프록시 URL로 대체합니다.
  Header edit* Link "https://GITHUB_ENTERPRISE_HOSTNAME" "https://PROXY_HOSTNAME"
</VirtualHost>

GitHub에서 GitLab로 프로젝트 가져오기

가져오기 기간 예측

전제 조건

권한 및 역할

사용자 기여 매핑을 위한 계정

알려진 문제

GitHub 리포지토리를 GitLab으로 가져오기

GitHub OAuth 사용하기

GitHub 개인 액세스 토큰 사용하기

API 사용하기

리포지토리 목록 필터링

가져올 추가 항목 선택

가져올 리포지토리 선택

가져오기 상태 확인

리포지토리 미러링 및 파이프라인 상태 공유

자가 관리 인스턴스에서 가져오기 속도 개선

Sidekiq 작업자 수 늘리기

GitHub Enterprise Cloud OAuth 앱을 사용하여 GitHub OAuth 활성화

가져온 데이터

브랜치 보호 규칙 및 프로젝트 설정

협력자 (회원)

내부 네트워크에서 GitHub Enterprise 가져오기

샘플 리버스 프록시 구성

도움말

기능 사용 가능성과 제품 평가판

도움받기