• 양방향 미러링에서 충돌 줄이기
• GitLab로 즉시 풀을 트리거하는 웹훅 구성
• 사전 수신 훅을 사용하여 충돌 방지
• Git Fusion을 사용한 Perforce Helix 미러링
• 관련 주제

양방향 미러링

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

양방향 미러링은 두 개의 리포지토리가 서로에서 가져오고, 서로에게 푸시하도록 구성합니다.
어떤 리포지토리도 오류 없이 업데이트할 수 있다는 보장은 없습니다.

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

양방향 미러링을 구성하는 경우 충돌에 대비하여 리포지토리를 준비하세요.
충돌을 줄이도록 구성하고, 발생할 때 해결하는 방법:

• 보호된 브랜치만 미러링합니다.
  원격에서 미러링된 커밋을 재작성하는 것은 충돌과 미러링 실패를 초래합니다.
• 보호할 브랜치를 설정하여 이력을 재작성하여 발생할 수 있는 충돌을 방지합니다.
• 푸시 이벤트 웹훅으로 미러링 지연을 줄입니다.
  양방향 미러링은 같은 브랜치에 가까운 시점에 커밋을 할 경우 충돌을 일으키는 경쟁 조건을 만듭니다.
  푸시 이벤트 웹훅은 경쟁 조건을 완화하는 데 도움이 될 수 있습니다.
  GitLab에서의 푸시 미러링은 보호된 브랜치에 대해서만 일 분에 한 번으로 제한됩니다.
• 사전 수신 훅을 사용하여 충돌 방지.

GitLab로 즉시 풀을 트리거하는 웹훅 구성

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

Prerequisites:

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

다운스트림 인스턴스에서 웹훅을 생성하려면:

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

4. 웹훅 URL을 추가합니다. 이 경우 Pull Mirror API
   요청을 사용하여 리포지토리 업데이트 후 즉시 풀을 트리거합니다:

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

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

통합을 테스트하려면 테스트를 선택하고 GitLab이 오류 메시지를 반환하지 않는지 확인합니다.

사전 수신 훅을 사용하여 충돌 방지

이 구성에서 하나의 Git 리포지토리는 권위 있는 업스트림 역할을 하고,
다른 하나는 다운스트림으로 작동합니다. 이 서버 측 pre-receive 훅은
먼저 커밋을 업스트림 리포지토리에 푸시한 후에만 푸시를 수락합니다.
이 훅을 다운스트림 리포지토리에 설치합니다.

예를 들어:

#!/usr/bin/env bash  

# --- 단 하나의 푸시 미러 대상만 가정  
# 푸시 미러링 원격은 `remote_mirror_<id>`로 명명됩니다.  
# 이 줄은 첫 번째 원격을 찾아서 사용합니다.  
TARGET_REPO=$(git remote | grep -m 1 remote_mirror)  

proxy_push()  
{  
  # --- 인수  
  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 "   원격 변경 사항을 먼저 통합하는 것이 좋습니다."  
          echo >&2 ""  
          return  
        fi  
      fi  
      ;;  
  esac  
}  

# 이중 모드 허용: 업데이트 훅처럼 명령줄에서 실행하거나  
# 인수가 주어지지 않으면 훅 스크립트로 실행:  
if [ -n "$1" -a -n "$2" -a -n "$3" ]; then  
  # 명령줄 모드에서 터미널로 출력합니다. 누군가 이메일을 다시 보낼 경우  
  # 출력을 리다이렉트하여 직접 sendmail을 사용할 수 있습니다.  
  PAGER= proxy_push $2 $3 $1  
else  
  # 푸시는 한 번에 하나의 참조로 업스트림으로 프록시됩니다.  
  # 몇몇 참조가 성공할 수 있고 다른 참조가 실패할 수 있습니다. 이는 실패한 푸시로 이어집니다.  
  while read oldrev newrev refname  
  do  
    proxy_push $oldrev $newrev $refname  
  done  
fi  

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

• 수정 없이 귀하의 용도에 맞지 않을 수 있습니다:
  • 미러에 대한 서로 다른 인증 메커니즘을 고려하지 않습니다.
  • 강제 업데이트(역사 재작성)에는 작동하지 않습니다.
  • allowlist 패턴과 일치하는 브랜치만 프록시로 푸시됩니다.
• 이 스크립트는 Git 훅 격리 환경을 우회합니다. $TARGET_REPO의 업데이트는 참조 업데이트로 간주되며
  Git은 이에 대한 경고를 표시합니다.

Git Fusion을 사용한 Perforce Helix 미러링

• 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 설정을 사용해야 합니다:

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

관련 주제

• 저장소 미러링에 대한 문제 해결
• 서버 훅 구성