双方向ミラーリング

双方向ミラーリングは、2つのリポジトリが互いにプルとプッシュの両方を行うように設定します。どちらのリポジトリもエラーなしに更新できるという保証はありません。

双方向ミラーリングにおける競合を軽減します

双方向ミラーリングを設定する場合は、競合に備えてリポジトリを準備してください。競合を軽減するように設定し、発生した場合の解決方法を設定します:

• 保護されたブランチのみをミラーリングする。いずれかのリモートでミラーリングされたコミットを書き換えると、競合が発生し、ミラーリングが失敗します。
• 両方のリモートでミラーするブランチを保護して、履歴の書き換えによって発生する競合を防ぎます。
• プッシュイベントを使用して、ミラーリングの遅延を軽減します。双方向ミラーリングは、同じブランチに対して互いに近い場所で作成されたコミットが競合を引き起こす競合状態を作成します。プッシュイベントは、競合状態を軽減するのに役立ちます。GitLabからのプッシュミラーリングは、保護ブランチをプッシュミラーリングする場合のみ、1分間に1回にレート制限されます。
• 事前受信フックの使用により、競合を防ぎます。

を設定して、GitLabへの即時プルをトリガーします

ダウンストリームインスタンスのプッシュイベントは、変更をより頻繁に同期することで、競合状態を軽減するのに役立ちます。

前提要件:

• アップストリームのGitLabインスタンスで、プッシュとプルミラーを設定しました。

ダウンストリームインスタンスでを作成するには:

1. API APIスコープでパーソナルアクセストークンを作成します。

2. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。

3. 設定 > Webhooksを選択します。

4. URLを追加します。このユースケースでは、リポジトリの更新後に即時プルをトリガーするプルミラーAPIリクエストを使用します:

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

5. Push Events（プッシュイベント） を選択します。

6. Add Webhook（Webhookを追加）を選択します。

インテグレーションをテストするには、テストを選択し、GitLabがエラーメッセージを返さないことを確認します。

事前受信フックを使用した競合の防止

この設定では、1つのGitリポジトリが信頼できるアップストリームとして機能し、もう1つがダウンストリームとして機能します。このサーバー側の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
}

# Allow dual mode: run from the command line just like the update hook, or
# if no arguments are given, then run as a hook script:
if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
  # Output to the terminal in command line mode. If someone wanted to
  # resend an email, they could redirect the output to sendmail themselves
  PAGER= proxy_push $2 $3 $1
else
  # Push is proxied upstream one ref at a time. It is possible for some refs
  # to succeed, and others to fail. This results in a failed push.
  while read oldrev newrev refname
  do
    proxy_push $oldrev $newrev $refname
  done
fi

このサンプルにはいくつかの制限があります:

• 変更なしでは、ユースケースでは機能しない場合があります:
  • ミラーのさまざまな種類の認証メカニズムを考慮していません。
  • 強制アップデート(履歴の書き換え)では機能しません。
  • allowlistパターンに一致するブランチのみがプロキシプッシュされます。
• スクリプトは、$TARGET_REPOの更新がrefsの更新と見なされ、Gitがそれに関する警告を表示するため、Gitフック検疫環境を回避します。

Git Fusionを使用したPerforce Helixとのミラー

Git Fusionは、Perforce HelixへのGitインターフェースを提供します。GitLabはPerforce Helixインターフェースを使用して、プロジェクトを双方向にミラーできます。オーバーラップするPerforce Helixワークスペースを同時に移行できない場合は、Perforce HelixからGitLabに移行する際に役立ちます。

Perforce Helixでミラーする場合は、保護ブランチのみをミラーしてください。Perforce Helixは、履歴を書き換えるプッシュを拒否します。Git Fusionのパフォーマンス上の制限により、ミラーするブランチの数は最小限にする必要があります。

Git Fusionを使用してPerforce Helixでミラーリングを構成する場合は、次のGit Fusion設定を使用する必要があります:

• change-pusherを無効にします。そうしないと、すべてのコミットは、既存のPerforce Helixユーザーまたはunknown_gitユーザーにマッピングするのではなく、ミラーリングアカウントによってコミットされたものとして書き換えられます。
• GitLabユーザーがPerforce Helixに存在しない場合は、unknown_gitユーザーをコミット作成者として使用します。

関連トピック

• リポジトリのミラーリングに関するトラブルシューティング。
• サーバーフック