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

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
  • GitLab 15.8에서 소개되었으며, GitLab은 더 이상 존재하지 않는 네임스페이스나 그룹을 자동으로 생성하지 않습니다. 또한, 네임스페이스나 그룹 이름이 사용 중이라면 더 이상 사용자의 개인 네임스페이스를 대체로 사용하지 않습니다.
  • GitLab 15.10에서 소개되었으며, GitLab에서는 이제 Require a pull request before merging - Allow specified actors to bypass required pull requests 브랜치 보호 규칙을 성공적으로 가져오려면 GitLab의 상위 그룹에 사용자를 추가할 필요가 없습니다.
  • GitLab 17.2에서 일부 가져온 항목에는 가져옴 뱃지가 있습니다. (소개됨)

GitHub 프로젝트를 GitHub.com 또는 GitHub Enterprise에서 가져올 수 있습니다. 프로젝트를 가져오면 GitHub에서 GitLab으로 어떠한 유형의 그룹이나 조직도 이전하거나 가져오지 않습니다.

caution
GitHub에서 GitLab.com으로 가져오는 것은 현재 사용할 수 없습니다. 문제의 해결에 걸리는 시간을 예측할 수 없습니다. 자세한 정보는 지원팀에 문의하십시오.

GitLab에서 가져온 문제, 병합 요청, 코멘트, 이벤트에는 가져옴 뱃지가 있습니다.

네임스페이스는 gitlab.com/sidney-jones 또는 gitlab.com/customer-success와 같이 GitLab의 사용자 또는 그룹입니다.

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

가져오기 전에 대상 네임스페이스와 대상 저장소 이름을 변경할 수 있습니다.

가져오기 프로세스 개요는 다음을 참조하십시오: GitHub에서 GitLab으로 이주하는 방법(Actions 포함).

가져오기 소요 시간 예측

GitHub에서의 각 가져오기가 다양하기 때문에 수행하는 가져오기의 기간에 영향을 미칩니다. 그러나 테스트에서 우리는 다음과 같은 프로젝트를 76시간 안에 가져왔습니다.

  • 80,000개의 pull 요청.
  • 45,000개의 이슈.
  • 약 150만 개의 코멘트.

전제 조건

GitHub에서 프로젝트를 가져오려면 GitHub 가져오기 원본을 활성화해야 합니다. 해당 가져오기 원본이 활성화되지 않은 경우 GitLab 관리자에게 활성화할 것을 요청하십시오. GitHub 가져오기 원본은 GitLab.com에서 기본적으로 활성화되어 있습니다.

권한과 역할

  • GitLab 16.0에서 Maintainer 역할 요구사항으로 소개되었으며, GitLab 15.11.1 및 GitLab 15.10.5로 후행 이전되었습니다.

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

  • 가져오기할 GitHub 프로젝트에 대한 액세스.
  • 가져오기할 대상 GitLab 그룹에서 적어도 Maintainer 역할.

또한, GitHub 리포지토리가 속한 조직은 가져오려는 GitLab 인스턴스에게 third-party application access policy 제한을 부과해서는 안 됩니다.

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

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

  • 리포지토리의 각 GitHub 작성자 및 담당자는 공개 공개 이메일 주소를 가져야 합니다.
  • GitHub 사용자의 이메일 주소는 GitLab 이메일 주소와 일치해야 합니다.
  • GitHub의 사용자 이메일 주소가 GitLab에서 이메일 주소 보조로 설정된 경우, 확인해야 합니다.

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

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

  • 프로젝트 생성자가 이슈 및 병합 요청의 작성자 및 담당자로 설정됩니다. 프로젝트 생성자는 일반적으로 가져오기 프로세스를 시작한 사용자입니다. 풀 요청에 추가된 리뷰어 및 승인 사항은 가져오지 않습니다. 이 경우, 가져오기자는 리뷰어 상태 및 승인을 병합 요청에 적용하지 않습니다.

알려진 문제

  • GitHub에서 2017년 이전에 만들어진 pull 요청 코멘트(이를 GitLab에서 diff 코멘트로 알려짐)는 별도의 쓰레드로 가져옵니다. 이는 2017년 이전에 만들어진 코멘트에 in_reply_to_id를 포함하지 않는 GitHub API의 제한으로 발생합니다.
  • GitHub Entreprise Server 인스턴스의 리포지토리에서의 Markdown 첨부 파일은 가져오지 않습니다 (알려진 문제 때문).
  • GitHub auto-merge를 사용한 프로젝트를 가져올 때, 가져온 GitLab 프로젝트에는 GitHub의 내부 GPG 키로 서명된 커밋이있는 경우 병합 커밋에 “unverified”라고 표시될 수 있습니다 (알려진 문제).
  • GitLab은 2023-05-09 이전에 개인 리포지토리에 업로드 된 GitHub Markdown 이미지 첨부 파일을 가져올 수 없습니다. 이 문제를 제공하고 해결에 도움을 주고 싶으며 귀하의 예제 리포지토리를 제공하려는 경우, 이슈 424046에 코멘트를 추가하면 연락을 받으실 수 있습니다.
  • GitLab-specific references의 경우, GitLab은 이슈에는 # 문자를 사용하고 병합 요청에는 ! 문자를 사용합니다. 그러나 GitHub는 문제와 병합 요청 모두에 대해 # 문자만 사용합니다. 가져오기 시:
    • 코멘트 노트의 경우, GitLab은 문제를 가리키는지 병합 요청을 가리키는지 결정할 수 없기 때문에 문제에 대한 링크만 생성합니다.
    • 문제 또는 병합 요청 개요의 경우, GitLab은 가져온 대상이 아직 대상에 생성되지 않았을 수 있으므로 어떠한 참조에 대해서도 링크를 생성하지 않습니다.

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

시작하기 전에, GitLab 사용자로 매핑하려는 모든 GitHub 사용자에게 공개적으로 표시되는 이메일 주소 와 일치하는 GitLab 이메일 주소가 있는지 확인하세요.

GitHub 사용자의 공개 이메일 주소가 GitLab 사용자의 이메일 주소와 일치하지 않는 경우 해당 사용자의 활동은 가져오기를 수행하는 사용자 계정과 연관됩니다.

GitHub 리포지토리를 다음 중 하나를 사용하여 가져올 수 있습니다:

github.com에서 가져올 때는 어떤 방법을 사용해도 됩니다. 온프레미스 GitHub Enterprise Server 고객은 API를 사용해야 합니다.

GitHub OAuth 사용

GitLab.com이나 GitHub OAuth가 구성됨으로써 자체 호스팅된 GitLab으로 가져오고자 하는 경우, GitHub OAuth를 사용하여 리포지토리를 가져올 수 있습니다.

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

  1. 왼쪽 사이드바에서 위쪽에 있는 새로 만들기 () 및 새 프로젝트/리포지토리를 선택합니다.
  2. 프로젝트 가져오기를 선택한 다음 GitHub을 선택합니다.
  3. GitHub 인증을 선택합니다.
  4. 가져올 리포지토리를 선택하기로 진행합니다.

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

GitHub 개인 액세스 토큰 사용

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

  1. GitHub 개인 액세스 토큰을 생성하세요. 클래식 개인 액세스 토큰만 지원됩니다.
    1. https://github.com/settings/tokens/new에 이동합니다.
    2. 노트 필드에 토큰 설명을 입력하세요.
    3. repo 스코프를 선택합니다.
    4. 선택 사항. 협력자 가져오기를 하려는 경우 또는 프로젝트에 Git LFS 파일이 있는 경우 read:org 스코프를 선택합니다.
    5. 토큰 생성을 선택합니다.
  2. GitLab 왼쪽 사이드바에서 위쪽에 있는 새로 만들기 () 및 새 프로젝트/리포지토리를 선택합니다.
  3. 프로젝트 가져오기를 선택한 다음 GitHub을 선택합니다.
  4. GitHub 인증을 선택합니다.
  5. 개인 액세스 토큰 필드에 GitHub 개인 액세스 토큰을 붙여넣으세요.
  6. 인증을 선택합니다.
  7. 가져올 리포지토리를 선택하기로 진행합니다.

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

API 사용

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

  • 공용이면 소유하지 않은 GitHub 리포지토리를 가져올 수 있습니다.
  • 자체 호스팅된 GitHub Enterprise Server에서 가져오기를 할 수 있습니다.
  • UI에서 제공되지 않는 timeout_strategy 옵션을 설정할 수 있습니다.

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

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

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

리포지토리 목록 필터링

GitHub 리포지토리에 대한 액세스를 인증하면 GitLab은 가져오기 페이지로 리디렉션하고 GitHub 리포지토리가 목록됩니다.

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

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

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

추가 가져올 항목 선택

  • GitLab 15.5에서 도입.
  • 협력자 가져오기를 추가 항목으로 설정하는 기능이 GitLab 16.0에서 도입.
  • Feature flag github_import_extended_events가 GitLab 16.8에서 도입되었습니다. 기본으로 비활성화됩니다. 이 플래그는 가져오기 성능을 개선하지만 이슈 및 풀 리퀘스트 이벤트 가져오기 옵션을 제거합니다.
  • Feature flag github_import_extended_events가 GitLab 16.9에서 GitLab.com과 자체 호스팅으로 설정되었습니다.
  • 개선된 가져오기 성능이 GitLab 16.11에서 일반적으로 사용 가능하게 되었습니다. Feature flag github_import_extended_events가 제거되었습니다.

가능한 빠른 가져오기를 위해 다음 항목은 GitHub로부터 기본적으로 가져오지 않습니다:

  • GitHub API의 제한 사항으로 인해 약 30,000개 이상의 댓글.
  • 리포지토리 코멘트, 릴리스 게시물, 이슈 설명 및 풀 리퀘스트 설명의 마크다운 첨부 파일. 이미지, 텍스트 또는 바이너리 첨부 파일이 포함될 수 있습니다. 가져오지 않으면 GitHub에서 첨부 파일을 제거한 후에는 마크다운에 첨부 파일 링크가 깨집니다.

이러한 항목을 가져오도록 선택할 수 있지만, 가져오는 데 시간이 많이 소요될 수 있습니다. 이러한 항목을 가져오려면 UI에서 적절한 필드를 선택하세요:

  • 대체 댓글 가져오기 방법 사용. 이슈와 풀 리퀘스트 전체적으로 30,000개 이상의 댓글이 있는 GitHub 프로젝트를 가져오는 경우, 이 방법을 활성화해야 합니다. 왜냐하면 GitHub API의 제한 사항 때문입니다.
  • 마크다운 첨부 파일 가져오기.
  • 협력자 가져오기 (기본으로 선택됨). 선택하면 새로운 사용자가 그룹 또는 네임스페이스에서 좌석을 사용할 수 있으며 프로젝트 소유자처럼 높은 권한이 부여될 수 있습니다. 직접적인 협력자만 가져옵니다. 외부 협력자는 가져오지 않습니다.

가져올 원격 저장소 선택

  • 보류 중이거나 활성 가져오기를 취소할 수 있는 기능은 GitLab 15.7에서 도입되었습니다.
  • 프로젝트를 다시 가져올 수 있는 기능은 GitLab 15.9에서 도입되었습니다.

기본적으로 제안된 저장소 네임스페이스는 GitHub에 있는 것과 동일한 이름과 일치하지만, 권한에 따라 진행하기 전에 이러한 이름을 편집할 수 있습니다.

가져올 원격 저장소를 선택하려면 여러 개의 저장소 중 하나 옆에 가져오기를 선택하거나 모든 저장소 가져오기를 선택합니다.

또한 이름으로 프로젝트를 필터링할 수 있습니다. 필터를 적용하면 모든 저장소 가져오기는 일치하는 저장소만 가져옵니다.

상태 열에는 각 저장소의 가져오기 상태가 표시됩니다. 페이지를 열어 실시간 업데이트를 확인하거나 나중에 다시 돌아올 수 있습니다.

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

가져온 프로젝트를 GitLab URL에서 여는 경우 가져오기 후 해당 GitLab 경로를 선택합니다.

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

GitHub 가져오기 페이지

가져오기 상태 확인

  • 완료되지 않은 가져오기의 세부 정보 및 가져오기에 실패한 엔터티 목록은 GitLab 16.1에서 도입되었습니다.

가져오기가 완료될 때 아래 중 하나의 상태일 수 있습니다:

  • 완료됨: GitLab이 모든 저장소 엔터티를 가져왔습니다.
  • 일부만 완료됨: GitLab이 일부 저장소 엔터티를 가져오지 못했습니다.
  • 실패함: GitLab이 중대한 오류가 발생한 후 가져오기를 중단했습니다.

세부 정보를 확장하여 가져오지 못한 저장소 엔터티 목록을 확인할 수 있습니다.

저장소 반영 및 파이프라인 상태 공유

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated

GitLab 티어에 따라 저장소 반영을 설정하여 가져온 저장소를 해당 GitHub 사본과 동기화할 수 있습니다.

또한 GitHub 프로젝트 통합을 사용하여 GitLab이 GitHub으로 파이프라인 상태 업데이트를 보낼 수 있습니다.

GitHub 프로젝트를 사용하여 프로젝트를 가져오면 위의 두 가지가 자동으로 구성됩니다.

참고: 반영은 GitHub 프로젝트의 새로운 또는 업데이트된 풀 리퀘스트를 동기화하지 않습니다.

자체 관리 인스턴스에서 가져오기 속도 향상

GitLab 서버에서 관리자 액세스 권한이 필요합니다.

Sidekiq 워커 수 증가

큰 프로젝트의 경우 모든 데이터를 가져오는 데 시간이 걸릴 수 있습니다. 필요한 시간을 줄이려면 Sidekiq 워커 수를 늘려야 합니다. 다음 큐를 처리하는 Sidekiq 워커 수를 늘릴 수 있습니다:

  • github_importer
  • github_importer_advance_stage

최상의 경험을 위해 CPU 코어 수와 동일한 수의 스레드를 실행하는 적어도 4개의 Sidekiq 프로세스(각각의 스레드 수만큼)가 필요합니다. 또한 이러한 프로세스가 별도의 서버에서 실행되는 것이 좋습니다. 8코어가 있는 4개 서버의 경우 각각 32개의 객체(예: 이슈)를 병렬로 가져올 수 있습니다.

클론하는 데 걸리는 시간을 줄이려면 네트워크 처리량, CPU 용량, 그리고 디스크 성능(예: 고성능 SSD 사용)을 늘리는 것이 도움이 됩니다. Sidekiq 워커 수를 늘리는 것은 저장소 클론에 필요한 시간을 줄이지 않습니다.

GitHub OAuth를 사용한 GitHub OAuth 활성화

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

일반적으로 GitHub API 요청은 시간당 5,000개의 요청으로 제한됩니다. 아래 단계를 사용하여 시간당 15,000개의 요청 제한을 얻을 수 있어 전체적인 가져오기 시간을 단축시킬 수 있습니다.

전제 조건:

높은 요청 제한을 활성화하려면:

  • GitHub에서 OAuth 앱을 생성하십시오. OAuth 앱이 개인 GitHub 계정이 아닌 Enterprise Cloud 조직에 의해 소유되도록 합니다.
  • GitHub OAuth를 사용하여 프로젝트 가져오기를 수행하십시오.
  • 선택 사항. 기본적으로 모든 구성된 OAuth 공급자에 대해 로그인이 활성화됩니다. GitHub OAuth를 가져오기에 사용하려면 GitHub로 로그인할 수 없지만 사용자가 GitHub 계정으로 GitLab 인스턴스에 로그인하는 것을 방지하려면 GitHub 로그인 비활성화할 수 있습니다.

가져온 데이터

다음 프로젝트 항목이 가져와집니다.

풀 리퀘스트와 이슈에 대한 참조가 보존됩니다. 가져온 각 저장소는 가시성 수준을 유지합니다. 가시성 수준이 제한(예: 가시성 수준 제한인 경우)된 경우 기본 프로젝트 가시성으로 설정됩니다.

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

내보낼 때, 지원되는 GitHub 브랜치 보호 규칙은 다음 중 하나로 매핑됩니다:

  • GitLab 브랜치 보호 규칙으로.
  • 프로젝트 전반적인 GitLab 설정으로.
GitHub 규칙 GitLab 규칙 소개된 버전
프로젝트의 기본 브랜치에 대한 병합 전에 대화 해결이 필요함 통합 요청에서의 모든 쓰레드는 해결되어야 함 프로젝트 설정 GitLab 15.5
병합하기 전에 풀 리퀘스트가 필요함 브랜치 보호 설정의 밀어넣기 및 병합이 허용된 사람 목록에서 아무도 GitLab 15.5
프로젝트의 기본 브랜치에 대한 서명된 커밋이 필요함 GitLab push 규칙의 서명되지 않은 커밋 거부 GitLab 15.5
강제 푸시 허용 - 모든 사용자 브랜치 보호 설정에서 강제 푸시 허용됨 GitLab 15.6
병합하기 전에 풀 리퀘스트가 필요함 - 코드 소유자의 검토 필요 브랜치 보호 설정의 코드 소유자 승인이 필요함 GitLab 15.6
병합하기 전에 풀 리퀘스트가 필요함 - 특정 사용자가 필요한 풀 리퀘스트 우회 가능 브랜치 보호 설정의 밀어넣기 및 병합이 허용된 사람 목록. 프리미엄 구독 없이는 푸시 및 병합이 허용되는 사용자 목록이 역할로 제한됨. GitLab 15.8

GitHub 규칙 병합하기 전에 상태 확인을 통과해야 함을 외부 상태 확인에 매핑하는 것은 이슈370948에서 고려되었으나, 이 규칙은 기술적으로 어려움으로 인해 프로젝트 가져오는 동안 GitLab로 가져와지지 않습니다. 그럼에도 불구하고 외부 상태 확인은 수동으로 생성할 수 있습니다.

협업자 (멤버)

이러한 GitHub 협업자 역할은 이러한 GitLab 멤버 역할에 매핑됩니다:

GitHub 역할 매핑된 GitLab 역할
Read Guest
Triage Reporter
Write Developer
Maintain Maintainer
Admin Owner

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

GitHub 협업자를 가져오려면 GitHub 프로젝트에서 최소 Write 역할이 있어야 합니다. 그렇지 않으면 협업자 가져오기가 건너뛰어집니다.

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

GitHub Enterprise 인스턴스가 인터넷에 접속할 수 없는 내부 네트워크에 있는 경우, GitLab.com이 인스턴스에 액세스하도록 허용하기 위해 역방향 프록시를 사용할 수 있습니다.

프록시는 다음을 해야합니다:

  • GitHub Enterprise 인스턴스로의 요청 전달.
  • 다음에서 내부 호스트 이름의 공개 프록시 호스트 이름으로 변환:
    • API 응답 본문.
    • API 응답 링크 헤더.

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

프록시를 구성한 후 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"

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

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로 인코딩된 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>