양방향 미러링

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated
  • 13.9에서 GitLab 프리미엄으로 이동되었습니다.

경고: 양방향 미러링은 충돌을 발생시킬 수 있습니다.

양방향 미러링은 두 저장소를 서로에서 풀 및 푸시할 수 있도록 구성합니다. 어느 저장소도 오류 없이 업데이트될 수 있는 것을 보장할 수 없습니다.

양방향 미러링에서의 충돌 줄이기

양방향 미러링을 구성하는 경우, 충돌을 줄이도록 저장소를 준비하세요. 충돌을 줄이고 발생할 때 어떻게 처리할지 구성하세요:

웹훅을 구성하여 GitLab로 즉시 풀을 트리거하세요

푸시 이벤트 웹훅은 다운스트림 인스턴스에서 변경 사항을 더 자주 동기화하여 경합 조건을 완화하는 데 도움이 될 수 있습니다.

필수 구성 요소:

  • 상위 GitLab 인스턴스에서 푸시 및 풀 미러를 구성했습니다.

다음과 같이 다운스트림 인스턴스에서 웹훅을 만들어보세요:

  1. API 범위로 개인 액세스 토큰을 구성했습니다.
  2. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  3. 설정 > 웹훅을 선택합니다.

  4. 웹훅 URL을 추가합니다. (이 경우) 레포지토리 업데이트 후에 즉시 풀을 트리거하는 요청에 Pull 미러 API를 사용하였습니다: 

    https://gitlab.example.com/api/v4/projects/:id/mirror/pull?private_token=<your_access_token>
  5. 푸시 이벤트를 선택합니다.
  6. 웹훅 추가를 선택합니다.

통합을 테스트하려면 테스트를 선택하고, GitLab에서 오류 메시지를 반환하지 않는지 확인하세요.

Pre-receive hook를 사용하여 충돌 방지

경고: 이 솔루션은 Git 푸시 작업의 성능에 부정적인 영향을 미칩니다. 왜냐하면 이 작업들은 상위 Git 저장소로 프록시됩니다.

이 구성에서 한 개의 Git 저장소가 권위 있는 상위로 작용하고, 다른 저장소는 하위로 작용합니다. 이 서버 측 pre-receive 후크는 커밋을 먼저 상위 저장소에 푸시한 후에만 푸시를 허용합니다. 이 후크를 하위 저장소에 설치하세요.

예를 들어: 

#!/usr/bin/env bash

# --- 단 하나의 푸시 미러 대상을 가정합니다
# 푸시 미러링 리모트는 `remote_mirror_<id>`로 명명됩니다.
# 이러한 라인은 첫 번째 리모트를 찾고 그것을 사용합니다.
TARGET_REPO=$(git remote | grep -m 1 remote_mirror)

proxy_push()
{
  # --- Arguments
  OLDREV=$(git rev-parse $1)
  NEWREV=$(git rev-parse $2)
  REFNAME="$3"

  # --- 브랜치 패턴을 프록시 푸시하는 데 사용
  allowlist=$(expr "$branch" : "\(master\)")

  case "$refname" in
    refs/heads/*)
      branch=$(expr "$refname" : "refs/heads/\(.*\)")

      if [ "$allowlist" = "$branch" ]; then
        # https://git-scm.com/docs/git-receive-pack#_quarantine_environment 처리
        unset GIT_QUARANTINE_PATH
        error="$(git push --quiet $TARGET_REPO $NEWREV:$REFNAME 2>&1)"
        fail=$?

        if [ "$fail" != "0" ]; then
          echo >&2 ""
          echo >&2 " 오류: 업스트림 서버에 의해 업데이트가 거부되었습니다"
          echo >&2 "   일반적으로 다른 저장소가 동일한 참조에 변경을 푸시해서 발생합니다. 먼저 원격 변경을 통합하세요"
          echo >&2 ""
          return
        fi
      fi
      ;;
  esac
}

# 이 샘플에는 몇 가지 제한 사항이 있습니다:
# - 수정 없이 사용 사례에 적합하지 않을 수 있습니다:
#   - 미러의 다른 유형의 인증 메커니즘을 고려하지 않습니다.
#   - 강제 업데이트(히스토리 재작성)와 작동하지 않습니다.
#   - `allowlist` 패턴과 일치하는 브랜치만 프록시 푸시됩니다.
# - 스크립트는 Git 후크 격리 환경을 우회합니다. 왜냐하면 `$TARGET_REPO`의 업데이트가 참조 업데이트로 간주되어서, Git에서 그에 대해 경고를 표시합니다.

Perforce Helix와 Git Fusion으로 미러링

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab Dedicated
  • 13.9에서 GitLab 프리미엄으로 이전되었습니다.

경고: 양방향 미러링은 영구적인 구성으로 사용해서는 안 됩니다. 대안적인 이주 방법은 Perforce Helix에서의 이주를 참조하십시오.

Git Fusion은 Perforce Helix에 대한 Git 인터페이스를 제공합니다. GitLab은 Perforce Helix 인터페이스를 사용하여 프로젝트를 양방향으로 미러링할 수 있습니다. 이는 Perforce Helix 워크스페이스가 중첩되어 동시에 마이그레이션되지 못할 때 GitLab으로부터 Perforce Helix로 마이그레이션할 때 도움이 될 수 있습니다.

Perforce Helix로 미러링하는 경우, 보호된 브랜치만 미러링하십시오. Perforce Helix는 히스토리를 다시 작성하는 푸시를 거부합니다. Git Fusion의 성능 제한으로 인해 가장 적은 수의 브랜치만 미러링해야 합니다.

Perforce Helix를 사용하여 Git Fusion으로 미러링을 구성할 때, 다음 Git Fusion 설정을 권장합니다:

  • change-pusher를 비활성화합니다. 그렇지 않으면 모든 커밋이 미러링 계정이 커밋한 것으로 다시 작성되어 기존 Perforce Helix 사용자나 unknown_git 사용자와 매핑되지 않습니다.
  • GitLab 사용자가 Perforce Helix에 존재하지 않을 경우 unknown_git 사용자를 커밋 작성자로 사용하십시오.

Perforce.com의 Git Fusion 설정에 대해 자세히 알아보기.

관련 주제