히스토리

• Imported 배지가 GitLab 17.2에서 도입되었습니다.
• Use alternative comments import method 체크박스가 GitLab 19.4에서 제거되었습니다. 이 댓글 가져오기 방법은 이제 새 가져오기에 항상 사용되며 끌 수 없습니다.

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

가져온 이슈, 머지 리퀘스트, 댓글, 이벤트에는 GitLab에서 Imported 배지가 표시됩니다.

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

GitLab UI를 사용하면 GitHub 가져오기 도구는 항상 github.com 도메인에서 가져옵니다. 자체 호스팅 GitHub Enterprise Server 도메인에서 가져오려면 api 범위를 가진 GitLab 액세스 토큰과 함께 가져오기 API GitHub 엔드포인트를 사용합니다.

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

가져오기 절차의 개요는 액션을 포함해 GitHub에서 GitLab으로 마이그레이션하는 방법을 참고합니다.

가져오기 기간 추정#

GitHub에서 수행하는 가져오기는 매번 다르며, 이에 따라 소요 시간도 달라집니다. 다만 테스트에서 GitLab은 https://github.com/kubernetes/kubernetes를 76시간에 가져왔습니다. 테스트 결과 이 프로젝트는 다음으로 구성되어 있었습니다:

• 풀 리퀘스트 80,000개.
• 이슈 45,000개.
• 댓글 약 150만 개.

사전 요구 사항#

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

권한 및 역할#

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

• 소스 GitHub 프로젝트에 대한 액세스
• 대상 GitLab 그룹의 Maintainer 또는 Owner 권한

또한 GitHub 리포지터리가 속한 조직은 가져오기 대상 GitLab 인스턴스에 타사 애플리케이션 액세스 정책의 제한을 적용하지 않아야 합니다.

알려진 문제#

• 2017년 이전에 작성된 GitHub 풀 리퀘스트 댓글(GitLab에서는 diff 노트라고 합니다)은 별도의 스레드로 가져옵니다. 2017년 이전 댓글에 in_reply_to_id를 포함하지 않는 GitHub API의 제한 때문입니다.

• GitLab 18.3 및 이전 버전에서는 GitHub Enterprise Server 인스턴스의 리포지터리에 있는 Markdown 첨부 파일을 가져오지 않습니다. GitLab 18.4 및 이후 버전에서는:

  • Markdown 첨부 파일 중 동영상과 이미지 파일만 가져옵니다.
  • 그 외 파일 첨부는 가져오지 않습니다.

• 알려진 문제 때문에 GitHub auto-merge를 사용한 프로젝트를 가져올 때, 커밋이 GitHub 내부 GPG 키로 서명되었다면 GitLab에서 가져온 프로젝트에 unverified로 표시된 머지 커밋이 생길 수 있습니다.

• GitLab은 2023-05-09 이전에 비공개 리포지터리에 업로드된 GitHub Markdown 이미지 첨부 파일을 가져올 수 없습니다. 이 문제가 발생하고 샘플 리포지터리를 제공할 의향이 있다면 이슈 424046에 댓글을 남기면 GitLab 이 연락합니다.

• GitLab 전용 참조에서 GitLab은 이슈에 # 문자를, 머지 리퀘스트에 ! 문자를 사용합니다. 그러나 GitHub는 이슈와 풀 리퀘스트 모두에 # 문자만 사용합니다. 가져올 때는 다음과 같습니다:

  • 댓글 노트에서는 참조가 이슈를 가리키는지 머지 리퀘스트를 가리키는지 GitLab 이 판별할 수 없으므로 이슈 링크만 생성합니다.
  • 이슈나 머지 리퀘스트 설명에서는 가져온 대응 항목이 대상에 아직 생성되지 않았을 수 있으므로 GitLab 이 어떤 참조에도 링크를 생성하지 않습니다.

• SAML 싱글 사인온(SSO)이 활성화된 GitHub 계정에서 가져오면 Markdown 첨부 파일 가져오기가 실패할 수 있습니다. SSO가 적용될 때 개인 액세스 토큰으로 자산을 내려받을 수 없는 GitHub API의 제한 때문입니다. 이 문제를 우회하려면 가져오기를 수행하는 GitLab 사용자를 GitHub 리포지터리의 외부 협업자로 추가합니다. 그러면 가져오는 동안 비공개 첨부 파일에 액세스할 수 있습니다.

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

GitHub 리포지터리는 다음 중 한 가지 방법으로 가져올 수 있습니다:

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

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

GitHub OAuth 사용#

GitLab.com으로 가져오거나 GitHub OAuth가 구성된 GitLab Self-Managed로 가져오는 경우 GitHub OAuth로 리포지터리를 가져올 수 있습니다.

이 방법은 백엔드가 적절한 권한으로 액세스 토큰을 교환하므로 개인 액세스 토큰(PAT) 사용보다 유리합니다.

1. 오른쪽 위에서 Create new (+)와 New project/repository를 선택합니다.
2. Import project를 선택한 다음 GitHub를 선택합니다.
3. Authorize with GitHub를 선택합니다.
4. 가져올 리포지터리 선택으로 진행합니다.

이 단계를 이미 수행한 뒤 다른 방법으로 가져오려면 GitLab 계정에서 로그아웃한 다음 다시 로그인합니다.

GitHub 개인 액세스 토큰 사용#

GitHub 개인 액세스 토큰으로 GitHub 리포지터리를 가져오려면 다음을 수행합니다:

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

이 단계를 이미 수행한 뒤 다른 토큰으로 가져오려면 GitLab 계정에서 로그아웃한 다음 다시 로그인하거나, GitHub에서 이전 토큰을 취소합니다.

API 사용#

가져오기 API로 GitHub 리포지터리를 가져올 수 있습니다. GitLab UI를 사용하는 것보다 몇 가지 장점이 있습니다:

• 공개 리포지터리라면 소유하지 않은 GitHub 리포지터리도 가져올 수 있습니다.
• 자체 호스팅 GitHub Enterprise Server에서 가져올 수 있습니다.
• UI에서는 제공되지 않는 timeout_strategy 옵션을 설정할 수 있습니다.

REST API는 GitLab 개인 액세스 토큰으로만 인증할 수 있습니다.

GitLab REST API로 GitHub 리포지터리를 가져오려면 다음을 수행합니다:

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

리포지터리 목록 필터링#

GitHub 리포지터리 액세스를 인가하면 GitLab 이 가져오기 도구 페이지로 리디렉션하고 GitHub 리포지터리가 나열됩니다.

다음 탭 중 하나를 사용해 리포지터리 목록을 필터링합니다:

• Owner (기본값): 본인이 소유한 리포지터리로 목록을 필터링합니다.
• Collaborated: 본인이 기여한 리포지터리로 목록을 필터링합니다.
• Organization: 본인이 멤버로 속한 조직의 리포지터리로 목록을 필터링합니다.

Organization 탭을 선택하면 드롭다운 목록에서 사용 가능한 GitHub 조직을 선택해 검색 범위를 더 좁힐 수 있습니다.

가져올 추가 항목 선택#

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

• 리포지터리 댓글, 릴리스 게시물, 이슈 설명, 풀 리퀘스트 설명의 Markdown 첨부 파일. 여기에는 이미지, 텍스트, 바이너리 첨부 파일이 포함될 수 있습니다. 가져오지 않으면 GitHub에서 첨부 파일을 제거한 뒤 Markdown의 첨부 파일 링크가 깨집니다.

이러한 항목을 가져오도록 선택할 수 있지만 가져오기 시간이 크게 늘어날 수 있습니다. 이러한 항목을 가져오려면 UI에서 해당 필드를 선택합니다:

• Import Markdown attachments.
• Import collaborators (기본적으로 선택됨). 선택된 상태로 두면 새 사용자가 그룹이나 네임스페이스의 좌석을 사용하고 프로젝트 소유자 수준까지 권한을 부여받을 수 있습니다. 직접 협업자만 가져옵니다. 외부 협업자는 가져오지 않습니다. GitLab 18.4 및 이후 버전에서는 협업자를 가져올 때 Users cannot be added to projects in this group 설정이 적용됩니다.

가져올 리포지터리 선택#

기본적으로 제안되는 리포지터리 네임스페이스는 GitHub에 있는 이름과 같지만, 보유한 권한에 따라 가져오기를 진행하기 전에 이 이름을 편집할 수 있습니다.

가져올 리포지터리를 선택하려면 원하는 리포지터리 옆에서 Import를 선택하거나 Import all repositories를 선택합니다.

또한 이름으로 프로젝트를 필터링할 수 있습니다. 필터를 적용하면 Import all repositories는 일치하는 리포지터리만 가져옵니다.

Status 칼럼은 리포지터리별 가져오기 상태를 보여 줍니다. 페이지를 열어 두고 실시간으로 업데이트를 지켜볼 수도 있고, 나중에 다시 방문할 수도 있습니다.

대기 중이거나 진행 중인 가져오기를 취소하려면 가져오는 프로젝트 옆에서 Cancel을 선택합니다. 가져오기가 이미 시작되었다면 가져온 파일은 유지됩니다.

가져온 뒤 GitLab URL에서 리포지터리를 열려면 해당 GitLab 경로를 선택합니다.

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

가져오기 상태 확인#

가져오기가 완료되면 세 가지 상태 중 하나가 됩니다:

• Complete: GitLab 이 모든 리포지터리 엔터티를 가져왔습니다.
• Partially completed: GitLab 이 일부 리포지터리 엔터티를 가져오지 못했습니다.
• Failed: 치명적인 오류가 발생해 GitLab 이 가져오기를 중단했습니다.

가져오지 못한 리포지터리 엔터티 목록을 보려면 Details를 확장합니다.

사용자 이름 멘션#

히스토리

• GitLab 17.5에서 도입되었습니다.

GitLab은 이슈, 머지 리퀘스트, 노트의 사용자 이름 멘션에 백틱을 추가합니다. 이 백틱은 GitLab 인스턴스에서 같은 사용자 이름을 가진 잘못된 사용자로 연결되는 것을 방지합니다.

사용자 기여 및 멤버십 매핑#

히스토리

• GitLab 17.8에서 사용자 기여 및 멤버십 매핑으로 GitLab.com에서 변경되었습니다.
• GitLab 17.8에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에 활성화되었습니다.

GitHub 가져오기 도구는 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 사용자 기여를 매핑할 때 마이그레이션 후 방식을 사용합니다.

대안적인 매핑 방법#

GitLab 18.7 및 이전 버전에서는 github_user_mapping 기능 플래그를 비활성화해 가져오기에 대안적인 사용자 기여 매핑 방법을 사용할 수 있습니다.

요구 사항:

• 리포지터리의 각 GitHub 작성자와 담당자는 공개용 이메일 주소를 보유해야 합니다. GitHub Enterprise는 공개 이메일 주소를 요구하지 않으므로 기존 계정에 추가해야 할 수 있습니다.
• GitHub 사용자의 이메일 주소는 해당 사용자의 GitLab 이메일 주소와 일치해야 합니다.
• GitHub의 사용자 이메일 주소가 GitLab에서 보조 이메일 주소로 설정되어 있으면 사용자가 이를 확인해야 합니다.

이 방법을 사용하면 가져오는 동안 사용자가 매핑됩니다.

요구 사항을 충족하지 않으면 가져오기 도구는 해당 사용자의 기여를 매핑할 수 없습니다. 이 경우 다음과 같습니다:

• 이슈와 머지 리퀘스트의 작성자와 담당자가 프로젝트 생성자로 설정됩니다. 프로젝트 생성자는 보통 가져오기 절차를 시작한 사용자입니다. 풀 리퀘스트, 이슈, 노트처럼 설명이나 노트가 있는 일부 기여에 대해서는 가져오기 도구가 원래 기여를 생성한 사람의 정보를 본문에 덧붙입니다.
• GitHub의 풀 리퀘스트에 추가된 리뷰어와 승인은 가져올 수 없습니다. 이 경우 가져오기 도구는 존재하지 않는 사용자가 리뷰어와 승인자로 추가되었다는 내용을 설명하는 댓글을 생성합니다. 다만 실제 리뷰어 상태와 승인은 GitLab의 머지 리퀘스트에 적용되지 않습니다.

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

GitLab 티어에 따라 리포지터리 미러링을 설정해 가져온 리포지터리를 GitHub 사본과 동기화된 상태로 유지할 수 있습니다.

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

외부 리포지터리용 CI/CD로 프로젝트를 가져오면 두 기능이 모두 자동으로 구성됩니다.

GitLab Self-Managed 인스턴스에서 가져오기 속도 개선#

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

Sidekiq 워커 수 늘리기#

대규모 프로젝트에서는 모든 데이터를 가져오는 데 시간이 걸릴 수 있습니다. 소요 시간을 줄이려면 다음 큐를 처리하는 Sidekiq 워커 수를 늘릴 수 있습니다:

• github_importer
• github_importer_advance_stage

최적의 경험을 위해서는 이 큐만 처리하는 Sidekiq 프로세스를 최소 4개(각각 CPU 코어 수와 같은 수의 스레드를 실행) 두는 것이 좋습니다. 또한 이 프로세스들은 별도의 서버에서 실행하는 것이 좋습니다. 8코어 서버 4대라면 오브젝트(예: 이슈)를 최대 32개까지 병렬로 가져올 수 있습니다.

리포지터리 복제에 걸리는 시간은 (GitLab 인스턴스의) Git 리포지터리를 저장하는 디스크의 네트워크 처리량, CPU 용량, 디스크 성능(예: 고성능 SSD 사용)을 높여 줄일 수 있습니다. Sidekiq 워커 수를 늘려도 리포지터리 복제에 걸리는 시간은 줄어들지 않습니다.

GitHub Enterprise Cloud OAuth App으로 GitHub OAuth 활성화#

GitHub Enterprise Cloud 조직에 속해 있다면 더 높은 GitHub API 속도 제한을 받도록 GitLab Self-Managed를 구성할 수 있습니다.

GitHub API 요청에는 보통 시간당 5,000회의 속도 제한이 적용됩니다. 아래 단계를 따르면 시간당 15,000회라는 더 높은 속도 제한을 받게 되어 전체 가져오기 시간이 빨라집니다.

사전 요구 사항:

• GitHub Enterprise Cloud 조직에 액세스할 수 있습니다.
• GitLab 이 GitHub OAuth를 활성화하도록 구성되어 있습니다.

더 높은 속도 제한을 활성화하려면 다음을 수행합니다:

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

가져오는 데이터#

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

• 열린 풀 리퀘스트와 관련된 프로젝트의 모든 포크 브랜치

  [!note] 포크 브랜치는 GH-SHA-username/pull-request-number/fork-name/branch와 비슷한 이름 규칙으로 가져옵니다.

• 모든 프로젝트 브랜치

• 다음의 첨부 파일:

  • 댓글
  • 이슈 설명
  • 풀 리퀘스트 설명
  • 릴리스 노트

• 브랜치 보호 규칙

• 협업자(멤버)

• Git LFS 오브젝트

• Git 리포지터리 데이터

• 이슈 및 풀 리퀘스트 댓글

• 이슈 및 풀 리퀘스트 이벤트(추가 항목으로 가져올 수 있습니다)

• 이슈

• 레이블

• 마일스톤

• 풀 리퀘스트에 지정된 리뷰어

• 풀 리퀘스트를 머지한 사용자 정보

• 풀 리퀘스트 리뷰

• 풀 리퀘스트 리뷰 댓글

• 풀 리퀘스트 리뷰의 토론 답글

• 풀 리퀘스트 리뷰 제안

• 풀 리퀘스트

• 릴리스 노트 내용

• 리포지터리 설명

• 위키 페이지

풀 리퀘스트와 이슈에 대한 참조는 유지됩니다. 가져온 각 리포지터리는 공개 수준을 유지하지만, 공개 수준이 제한된 경우에는 기본 프로젝트 공개 수준으로 설정됩니다.

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

가져온 GitHub 브랜치 보호 규칙은 다음 중 하나로 매핑됩니다:

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

Require status checks to pass before merging GitHub 규칙은 가져오지 않습니다. 외부 상태 확인은 수동으로 만들 수 있습니다. 자세한 내용은 이슈 370948을 참고합니다.

협업자(멤버)#

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

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

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

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

GitHub Enterprise 인스턴스가 인터넷에서 접근할 수 없는 내부 네트워크에 있다면 리버스 프록시를 사용해 GitLab.com 이 해당 인스턴스에 액세스하도록 할 수 있습니다.

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

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

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

프록시를 구성한 뒤 API 요청을 보내 테스트합니다. 아래는 API를 테스트하는 예시 명령입니다:

curl --header "Authorization: Bearer " "https://{PROXY_HOSTNAME}/user"

### URLs in the response body should use the proxy hostname

{
  "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 " "https://{PROXY_DOMAIN}/api/v3/repos/{repository_path}/pulls?states=all&sort=created&direction=asc"

### Link header should use the proxy hostname

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 Server를 리버스 프록시로 구성하는 예시입니다.

# Required modules
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


  ServerName GITHUB_ENTERPRISE_HOSTNAME

  # Enables reverse-proxy configuration with SSL support
  SSLProxyEngine On
  ProxyPass "/" "https://GITHUB_ENTERPRISE_HOSTNAME/"
  ProxyPassReverse "/" "https://GITHUB_ENTERPRISE_HOSTNAME/"

  # Replaces occurrences of the local GitHub Enterprise URL with the Proxy URL
  # GitHub Enterprise compresses the responses, the filters INFLATE and DEFLATE needs to be used to
  # decompress and compress the response back
  AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE application/json
  Substitute "s|https://GITHUB_ENTERPRISE_HOSTNAME|https://PROXY_HOSTNAME|ni"
  SubstituteMaxLineLength 50M

  # GitHub API uses the response header "Link" for the API pagination
  # For example:
  #   <https://example.com/api/v3/repositories/1/issues?page=2>; rel="next", <https://example.com/api/v3/repositories/1/issues?page=3>; rel="last"
  # The directive below replaces all occurrences of the GitHub Enterprise URL with the Proxy URL if the
  # response header Link is present
  Header edit* Link "https://GITHUB_ENTERPRISE_HOSTNAME" "https://PROXY_HOSTNAME"
</VirtualHost>

관련 주제#

• 가져오기 및 내보내기 설정.
• 가져오기용 Sidekiq 구성.
• 여러 Sidekiq 프로세스 실행.
• 특정 job 클래스 처리.