• 양방향 미러링에서의 충돌 감소
• 웹훅 구성하여 GitLab에서 즉각적인 풀 수행
• pre-receive 후크를 사용하여 충돌 방지
• Perforce Helix와 Git Fusion으로 미러링
• 관련 주제

양방향 미러링

• 13.9에서 GitLab Premium으로 이동되었습니다.

양방향 미러링은 두 리포지터리를 서로에서 페치하고 푸시하는 방식으로 구성합니다. 어떤 리포지터리도 오류 없이 업데이트될 수 있다는 보장은 없습니다.

양방향 미러링에서의 충돌 감소

양방향 미러링을 구성하는 경우 충돌에 대비하여 리포지터리를 준비하세요. 충돌을 줄이고 발생 시 어떻게 해결할지 구성하세요:

• 보호된 브랜치만 미러링. 어느 한 리모트에서 미러링된 커밋을 다시 작성하면 충돌이 발생하고 미러링이 실패합니다.
• 미러링하려는 브랜치를 보호하세요. 이력을 다시 작성하여 발생하는 충돌을 방지하기 위해 양쪽 리모트에서 미러링하려는 브랜치를 보호하세요.
• 푸시 이벤트 웹훅으로 미러링 지연 시간을 줄이세요. 양방향 미러링은 동일한 브랜치에 대거 가까이 발생한 커밋으로 인해 레이스 조건이 생성됩니다. 푸시 이벤트 웹훅은 레이스 조건을 완화하는 데 도움이 될 수 있습니다. 푸시 미러링은 보호된 브랜치만 푸시하면 1분에 한 번으로 제한됩니다.
• pre-receive 후크를 사용하여 충돌을 방지하세요.

웹훅 구성하여 GitLab에서 즉각적인 풀 수행

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

필수 사항:

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

다음과 같이 다운스트림 인스턴스에서 웹훅을 생성하세요:

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

4. 웹훅 URL을 추가합니다. (이 경우) 리포지터리 업데이트 후 즉각적인 풀을 시작하도록 풀 미러 API 요청을 사용하는 경우:

   https://gitlab.example.com/api/v4/projects/:id/mirror/pull?private_token=<your_access_token>
   

5. 푸시 이벤트를 선택합니다.
6. 웹훅 추가를 선택합니다.

통합 테스트를 위해 테스트를 선택하고, GitLab에서 오류 메시지를 반환하지 않는지 확인합니다.

pre-receive 후크를 사용하여 충돌 방지

이 구성에서 한 Git 리포지터리는 권위 있는 상위 리포지터리로, 다른 하나는 하위 리포지터리로 작동합니다. 서버측 pre-receive 후크는 먼저 커밋을 상위 리포지터리에 푸시한 후에만 푸시를 허용합니다. 이 후크를 다운스트림 리포지터리에 설치하세요.

예시:

#!/usr/bin/env bash

# --- Assume only one push mirror target
# Push mirroring remotes are named `remote_mirror_<id>`.
# This line finds the first remote and uses that.
TARGET_REPO=$(git remote | grep -m 1 remote_mirror)

proxy_push()
{
  # --- Arguments
  OLDREV=$(git rev-parse $1)
  NEWREV=$(git rev-parse $2)
  REFNAME="$3"
  
  # --- Pattern of branches to proxy pushes
  allowlist=$(expr "$branch" : "\(master\)")
  
  case "$refname" in
    refs/heads/*)
      branch=$(expr "$refname" : "refs/heads/\(.*\)")
      
      if [ "$allowlist" = "$branch" ]; then
        # handle 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 " Error: updates were rejected by upstream server"
          echo >&2 "   This is usually caused by another repository pushing changes"
          echo >&2 "   to the same ref. You may want to first integrate remote changes"
          echo >&2 ""
          return
        fi
      fi
      ;;
  esac
}

# 이런식으로 몇가지 제한사항이 존재합니다:
# - 수정 없이 별도의 인증 메커니즘들은 작동하지 않을 수 있습니다:
# - 강제 업데이트(이력 다시 작성)와 작동하지 않음
# - `allowlist` 패턴과 일치하는 브랜치만 프록시 푸시됩니다
# - 스크립트는 업데이트된 `$TARGET_REPO`가 참조로 인식하기에 권한 환경의 Git 후크 경고가 표시됩니다.

# 커맨드 라인에서 업데이트 후크처럼 이중 모드 허용: 
# 만약 누군가가 이메일을 재전송하길 원한다면 출력을 직접 sendmail로 이동시킬 수 있습니다.
if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
  # 화면에 출력됨
  PAGER= proxy_push $2 $3 $1
else
  # 푸시는 상위로 프록시로 메인 리프의 하나에 대해 이루어집니다.
  몇몇 레프가 성공적이고, 다른것들이 실패할 수 있습니다. 이것은 실패한 푸시로 이어집니다.
  while read oldrev newrev refname
  do
    proxy_push $oldrev $newrev $refname
  done
fi

이 샘플은 몇 가지 제한 사항이 있습니다:

• 수정 없이 다양한 인증 메커니즘이 작동하지 않을 수 있습니다:
  • 미러링을 위한 다양한 브랜치만 프록시 푸시됩니다.
• 스크립트는 업데이트된 $TARGET_REPO가 참조로 인식하며 Git은 경고 표시합니다.

Perforce Helix와 Git Fusion으로 미러링

• 13.9에서 GitLab Premium으로 이동되었습니다.

Git Fusion은 Perforce Helix에 대한 Git 인터페이스를 제공합니다. GitLab은 Perforce Helix 워크스페이스가 동시에 마이그레이션되지 못할 경우 도움이 될 수 있으며, Perforce Helix에서 GitLab으로 마이그레이션할 때 도움이 될 수 있습니다.

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 설정을 읽어보세요.

관련 주제

• 리포지터리 미러링에 대한 문제 해결.
• 서버 후크 구성