원격 저장소에서 끌어오기

Tier: 프리미엄, 얼티밋 Offering: GitLab.com, 자체 관리, GitLab 전용

13.9에서 GitLab 프리미엄으로 이전되었습니다.

GitLab 인터페이스를 사용하여 리모트에 호스팅되지 않는 저장소의 내용 및 활동을 둘러볼 수 있습니다. 풀 거울을 만들어 상위 저장소의 브랜치, 태그 및 커밋을 여러분의 저장소로 복제할 수 있습니다.

푸시 거울과는 달리, 풀 거울은 상위(원격) 저장소에서 일정한 주기로 변경 사항을 검색합니다. 여러분의 저장소로 직접 커밋을 푸시하지 않고 위류(상위) 저장소로 커밋을 푸시하여 거울이 위류(상위) 저장소와 달라지지 않도록 해야 합니다. 원격 저장소의 변경 사항은 GitLab 저장소로 끌어옵니다:

이전 풀 후 30분 후 자동으로. 이 기능은 사용할 수 없습니다.
관리자가 거울 강제 업데이트를 실행했을 때.
API 호출이 업데이트를 트리거했을 때.

UI 및 API 업데이트는 기본 풀 거울링 간격이 5분입니다. 이 간격은 자체 관리형 인스턴스에서 구성할 수 있습니다.

기본적으로 풀 거울의 어떤 브랜치나 태그가 로컬 저장소와 달라지면 GitLab은 해당 브랜치의 업데이트를 중지합니다. 이는 데이터 손실을 방지합니다. 상위 저장소에서 삭제된 브랜치 및 태그는 하위 저장소에 반영되지 않습니다.

참고: 하위 풀 거울 저장소에서 삭제된 항목이 상위 저장소에 여전히 남아 있는 경우, 해당 항목은 다음 풀 후에 복원됩니다. 예: 거울 저장소에서 단지 삭제된 브랜치는 다음 풀 후에 다시 나타납니다.

풀 거울링 작동 방식

GitLab 저장소를 풀 거울로 구성한 후:

GitLab은 해당 저장소를 대기열에 추가합니다.
1분마다, Sidekiq cron 작업은 저장소 거울을 업데이트할 예정 시간을 기반으로 예약합니다:
- 사용 가능한 용량, Sidekiq 설정에 따라 결정됩니다. GitLab.com의 경우, GitLab.com Sidekiq 설정을 참조하세요.
- 이미 대기열에 추가되어 있고 업데이트를 기다리는 거울의 수에 따라 달라집니다. 예정된 시간은 저장소 거울이 마지막으로 언제 업데이트되었는지와 업데이트가 몇 번 다시 시도되었는지에 따라 달라집니다.
Sidekiq이 업데이트를 처리할 수 있게 되면, 거울이 업데이트됩니다. 업데이트 프로세스:
- 성공: 30분 이상의 대기 시간을 가진 새 업데이트가 다시 대기열에 추가됩니다.
- 실패: 나중에 다시 시도됩니다. 14번의 실패 후에 거울은 강제 실패 상태로 표시되어 더 이상 업데이트 대기열에 추가되지 않습니다. 브랜치가 상위 브랜치와 달라짐으로 인해 실패가 발생할 수 있습니다. 브랜치가 달라지지 않도록 하려면 거울을 생성할 때 달라진 브랜치 덮어쓰기를 구성하세요.

풀 거울링 구성

전제 조건:

만약 원격 저장소가 GitHub에 있고 이중 인증(2FA) 구성이 되어 있다면, repo 스코프를 가진 GitHub 개인 액세스 토큰 생성해야 합니다. 2FA가 활성화되어 있으면, 해당 개인 액세스 토큰은 여러분의 GitHub 비밀번호로 사용됩니다.
GitLab Silent Mode이 활성화되어 있지 않아야 합니다.

좌측 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
설정 > 저장소를 선택합니다.
거울링 저장소를 확장합니다.
Git 저장소 URL을 입력합니다.
참고: gitlab 저장소를 거울링하려면 gitlab.com:gitlab-org/gitlab.git 또는 https://gitlab.com/gitlab-org/gitlab.git을 사용하세요.
거울 방향에서 풀을 선택합니다.
인증 방법에서 여러분의 인증 방법을 선택합니다. 자세한 내용은 거울용 인증 방법을 참조하세요.
필요한 옵션을 선택합니다:
- 달라진 브랜치 덮어씌우기
- 거울 업데이트에 대한 파이프라인 트리거
- 보호된 브랜치만 거울링
구성을 저장하려면 저장소 거울링을 선택합니다.

달라진 브랜치 덮어씌우기

13.9에서 GitLab 프리미엄으로 이전되었습니다.

항상 로컬 브랜치를 원격 버전과 업데이트하려면 거울을 만들 때 달라진 브랜치 덮어씌우기를 선택하세요.

경고: 거울링된 브랜치에 대해 이 옵션을 활성화하면 로컬 변경 사항이 손실됩니다.

미러 업데이트를 위한 파이프라인 트리거

13.9에서 GitLab 프리미엄으로 이전됨.

이 옵션이 활성화되면, 원격 저장소에서 브랜치나 태그가 업데이트될 때마다 파이프라인이 트리거됩니다. 원격 저장소의 활동에 따라 CI 러너에 대한 부하가 크게 증가할 수 있습니다. 부하를 처리할 수 있다고 확신하는 경우에만이 기능을 활성화하세요. CI는 풀 미러링을 설정할 때 할당된 자격 증명을 사용합니다.

API를 사용하여 업데이트 트리거

13.9에서 GitLab 프리미엄으로 이전됨.

풀 미러링은 폴링을 사용하여 새로운 브랜치와 커밋이 상위 저장소에 추가된 것을 감지하며, 종종 몇 분 후에 감지됩니다. API 호출을 사용하여 GitLab에 알릴 수 있지만, 풀 미러링 강제 업데이트 간격 제한은 여전히 적용됩니다.

더 많은 정보는 프로젝트의 풀 미러링 프로세스 시작를 읽어보세요.

미러링 중 하드 실패 수정

13.9에서 GitLab 프리미엄으로 이전됨.

실패한 재시도가 14번 연속으로 발생하면 미러링 프로세스가 하드 실패로 표시되고 미러링 시도가 중지됩니다. 이 실패는 다음 위치에서 확인할 수 있습니다:

프로젝트의 주 대시보드.
풀 미러 설정 페이지.

프로젝트 미러링을 다시 시작하려면, 강제 업데이트를 실행하세요.

이 문제로 많은 프로젝트에 영향을 미치는 경우, 예를 들어 긴 네트워크 또는 서버 장애 후에, 다음 명령을 사용하여 해당 문제가 있는 모든 프로젝트를 식별하고 업데이트할 수 있습니다:

Project.find_each do |p|
  if p.import_state && p.import_state.retry_count >= 14
    puts "Resetting mirroring operation for #{p.full_path}"
    p.import_state.reset_retry_count
    p.import_state.set_next_execution_to_now(prioritized: true)
    p.import_state.save!
  end
end

원격 저장소에서 끌어오기

풀 거울링 작동 방식

풀 거울링 구성

달라진 브랜치 덮어씌우기

미러 업데이트를 위한 파이프라인 트리거

API를 사용하여 업데이트 트리거

미러링 중 하드 실패 수정

관련 주제

도움말

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

도움받기