グループとプロジェクトのインポートと移行

既存の作業をGitLabに取り込み、コントリビュート履歴を保持します。複数のプラットフォームからプロジェクトを統合するか、GitLabインスタンス間でデータを転送します。

GitLabには、次の方法があります:

• 直接転送を使用してGitLabグループとプロジェクトを移行します。
• さまざまなサポート対象ソースからプロジェクトをインポートします。

直接転送を使用してGitLabからGitLabに移行する

GitLabインスタンス間、または同じGitLabインスタンス内でGitLabグループとプロジェクトをコピーする最適な方法は、直接転送を使用することです。

別のオプションは、グループ転送を使用してGitLabグループを移動することです。

GitLabファイルのエクスポートを使用してもGitLabプロジェクトをコピーできます。これは、サポートされているインポートソースです。

サポートされているインポートソース

デフォルトで使用できるインポートソースは、使用するGitLabによって異なります:

• GitLab.com: 使用可能なすべてのインポートソースは、デフォルトで有効になっています。
• GitLab Self-Managed: インポートソースはデフォルトで有効になっていないため、有効にする必要があります。

GitLabは、これらのサポートされているインポートソースからプロジェクトをインポートできます。

移行を開始した後、移行元インスタンスでインポートされたグループまたはプロジェクトを変更しないでください。これらの変更が移行先インスタンスにコピーされない可能性があります。

未使用のインポートソースを無効にする

信頼できるソースからのみプロジェクトをインポートします。信頼できないソースからプロジェクトをインポートすると、攻撃者が機密データを盗む可能性があります。たとえば、悪意のある.gitlab-ci.ymlファイルを含むインポートされたプロジェクトでは、攻撃者がグループCI/CD変数を流出させる可能性があります。

GitLab Self-Managedの管理者は、不要なインポートソースを無効にすることで、アタックサーフェス（攻撃対象領域）を削減できます:

1. 左側のサイドバーの下部で、管理者を選択します。
2. 設定 > 一般を選択します。
3. 設定のインポートとエクスポートを展開します。
4. ソースをインポートまでスクロールします。
5. 不要なインポーターのチェックボックスをオフにします。

その他のインポートソース

次のその他のインポートソースからのインポートに関する情報を読むこともできます:

• ClearCase
• Concurrent Versions System（CVS）
• Jira（イシューのみ）
• Perforce Helix
• Team Foundation Version Control（TFVC）

サブバージョンからリポジトリをインポートする

GitLabは、サブバージョンリポジトリをGitに自動的に移行することはできません。サブバージョンリポジトリからGitへの変換は困難な場合がありますが、次のようなツールがいくつか存在します:

• git svnは、非常に小さく基本的なリポジトリ用です。
• reposurgeonは、より大きく複雑なリポジトリ用です。

ユーザーコントリビューションとメンバーシップのマッピング

このユーザーコントリビュートおよびメンバーシップマッピングの方法は、GitLab.comおよびGitLab Self-Managedの直接転送 、GitHubインポーター 、Bitbucket Serverインポーター 、およびGiteaインポーターでデフォルトで使用できます。機能フラグが無効になっているGitLab Self-Managedで利用可能な別の方法については、各インポーターのドキュメントを参照してください。

インポートするメンバーシップとコントリビュートは、最初にプレースホルダーユーザーにマッピングされます。これらのプレースホルダーは、移行元インスタンスに同じメールアドレスを持つユーザーが存在する場合でも、移行先インスタンスに作成されます。移行先インスタンスでコントリビュートを再アサインするまで、すべてのコントリビュートはプレースホルダーに関連付けられているものとして表示されます。

インポートが完了したら、次のことができます:

• 結果をレビューした後、移行先インスタンスの既存のユーザーにメンバーシップとコントリビュートを再アサインします。移行元インスタンスと移行先インスタンスで異なるメールアドレスを持つユーザーのメンバーシップとコントリビュートをマッピングできます。
• メンバーシップとコントリビュートを再アサインするために、移行先インスタンスで新しいユーザーを作成します。

コントリビュートを移行先インスタンスのユーザーに再アサインすると、ユーザーは再アサインを承認または拒否できます。ユーザーが再割り当てを承認すると、次のようになります:

• コントリビュートが再割り当てされます。この処理には数分かかる場合があります。
• その後、同じソースインスタンスから、宛先インスタンス上の同じトップレベルグループまたはサブグループにインポートすると、コントリビュートはユーザーに自動的にマッピングされます。

GitLab 18.0以降では、トップレベルグループに少なくとも1人のエンタープライズユーザーがいる場合、UIで、またはCSVファイルを使用して、組織内のエンタープライズユーザーにのみコントリビュートを再アサインできます。この機能は、組織外のユーザーへの誤った再アサインを防止するためのものです。

要件

• ユーザー制限に従って、十分な数のユーザーを作成できる必要があります。
• GitLab.comにインポートする場合は、インポートする前に有料のネームスペースを設定する必要があります。
• GitLab.comにインポートし、GitLab.comグループにSAML SSOを使用する場合は、コントリビュートとメンバーシップを再アサインする前に、すべてのユーザーがSAML IDをGitLab.comアカウントにリンクする必要があります。

プレースホルダーユーザー

コントリビュートとメンバーシップを移行先インスタンスのユーザーにすぐに割り当てる代わりに、インポートされたコントリビュートまたはメンバーシップを持つアクティブ、無効、またはボットのユーザーに対してプレースホルダーユーザーが作成されます。ソースインスタンスで削除されたユーザーの場合、すべてのプレースホルダーユーザー属性なしでプレースホルダーが作成されます。これらのユーザーをプレースホルダーとして保持する必要があります。詳細については、イシュー506432を参照してください。

コントリビュートとメンバーシップの両方が最初にこれらのプレースホルダーユーザーに割り当てられ、インポート後に移行先インスタンスの既存のユーザーに再アサインできます。再アサインされるまで、コントリビュートはプレースホルダーに関連付けられているものとして表示されます。プレースホルダーのメンバーシップは、メンバーリストには表示されません。

プレースホルダーユーザーは、ライセンス制限にはカウントされません。

例外

プレースホルダーユーザーは、次のシナリオを除き、移行元インスタンスの各ユーザーに対して作成されます:

• Giteaからプロジェクトをインポートしており、ユーザーがインポート前にGiteaで削除されている。これらのユーザーからのコントリビュートは、プレースホルダーユーザーではなく、プロジェクトをインポートしたユーザーにマッピングされます。
• プレースホルダーユーザー制限を超過しました。制限を超過した後の新しいユーザーからのコントリビュートは、Import Userという単一の非機能ユーザーにマッピングされます。
• パーソナルネームスペースにインポートしており、user_mapping_to_personal_namespace_owner機能フラグが有効になっています。コントリビュートは、パーソナルネームスペースのオーナーに割り当てられます。user_mapping_to_personal_namespace_ownerが無効になっている場合、すべてのコントリビュートは、Import Userという単一の非機能ユーザーに割り当てられます。

プレースホルダーユーザー属性

プレースホルダーユーザーは通常のユーザーとは異なり、次のことはできません:

• サインイン。
• アクションを実行する。たとえば、パイプラインの実行などです。
• イシューおよびマージリクエストの担当者またはレビュアーとして候補に表示されます。
• プロジェクトおよびグループのメンバーになる。

ソースインスタンス上のユーザーとの接続を維持するために、プレースホルダーユーザーには次のものがあります:

• 新しいプレースホルダーユーザーが必要かどうかをインポートプロセスが判断するために使用する固有識別子（source_user_id）。
• ソースホスト名またはドメイン（source_hostname）。
• コントリビュートの再割り当てを支援するためのソースユーザーの名前（source_name）。
• コントリビュートの再アサイン中にグループオーナーを支援するためのソースユーザーのユーザー名(source_username)。
• どのインポーターがプレースホルダーを作成したかを区別するインポートタイプ（import_type）。
• 移行追跡のために移行元ユーザーが作成されたときのタイムスタンプ（created_at）（ローカル時刻）（GitLab 17.10で導入）。

履歴コンテキストを保持するために、プレースホルダーユーザー名とユーザー名は、移行元ユーザー名とユーザー名から派生します:

• プレースホルダーユーザーの名前はPlaceholder <source user name>です。
• プレースホルダーユーザーのユーザー名は%{source_username}_placeholder_user_%{incremental_number}です。

プレースホルダーユーザーを表示する

前提要件:

• グループのオーナーのロールを持っている必要があります。

トップレベルグループとそのサブグループへのインポート中に、プレースホルダーユーザーが移行先インスタンスに作成されます。トップレベルグループとそのサブグループへのインポート中に作成されたプレースホルダーユーザーを表示するには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。

プレースホルダーユーザーをフィルタリングする

前提要件:

• インスタンスへの管理者アクセス権が必要です。

トップレベルグループとそのサブグループへのインポート中に、プレースホルダーユーザーが移行先インスタンスに作成されます。インスタンス全体のインポート中に作成されたプレースホルダーユーザーをフィルタリングするには:

1. 左側のサイドバーの下部で、管理者を選択します。
2. 概要 > ユーザーを選択します。
3. 検索ボックスで、type（タイプ）でユーザーをフィルタリングします。

プレースホルダーユーザーを作成する

プレースホルダーユーザーは、インポートソースおよびトップレベルグループごとに作成されます:

• 同じプロジェクトを移行先インスタンスの同じトップレベルグループに2回インポートする場合、2回目のインポートでは最初のインポートと同じプレースホルダーユーザーが使用されます。
• 同じプロジェクトを2回インポートしても、移行先インスタンスの異なるトップレベルグループにインポートする場合、2回目のインポートではそのトップレベルグループの下に新しいプレースホルダーユーザーが作成されます。

ユーザーが再アサインを承認すると、同じソースインスタンスから、宛先インスタンス上の同じトップレベルグループまたはサブグループにインポートしても、プレースホルダーユーザーは作成されません。代わりに、コントリビュートはユーザーに自動的にマッピングされます。

プレースホルダーユーザーの削除

トップレベルグループにプレースホルダユーザーが含まれている場合、これらのユーザーは自動的に削除されるようにスケジュールされます。この処理が完了するまでに時間がかかることがあります。ただし、プレースホルダユーザーが他のプロジェクトまたはグループにも関連付けられている場合は、システムに残ります。

プレースホルダーユーザー制限

GitLab.comにインポートする場合、プレースホルダーユーザーは、移行先インスタンスのトップレベルグループごとに制限されます。制限は、プランとシート数によって異なります。プレースホルダーユーザーは、ライセンス制限にはカウントされません。

GitLab Self-ManagedおよびGitLab Dedicatedの場合、デフォルトではプレースホルダー制限は適用されません。GitLab管理者は、インスタンスのプレースホルダー制限を設定できます。

現在のプレースホルダーユーザーの使用量と制限を表示するには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 設定 > 使用量クォータを選択します。
3. インポートタブを選択します。

事前に必要なプレースホルダーユーザーの数を判断することはできません。

プレースホルダーユーザー制限に達すると、すべてのコントリビュートがImport Userという単一の非機能ユーザーに割り当てられます。Import Userに割り当てられたコントリビュートは重複排除される可能性があり、インポート中に一部のコントリビュートが作成されない可能性があります。たとえば、マージリクエストの承認者からの複数の承認がImport Userに割り当てられている場合、最初の承認のみが作成され、その他は無視されます。重複排除される可能性のあるコントリビュートは次のとおりです:

• 承認ルール
• 絵文字リアクション
• イシューの担当者
• メンバーシップ
• マージリクエストの承認、担当者、レビュアー
• プッシュ、マージリクエスト、およびデプロイのアクセスレベル

すべての変更によってシステムノートが作成されます。これは、プレースホルダーユーザー制限の影響を受けません。

コントリビュートとメンバーシップの再アサイン

トップレベルグループのオーナーロールを持つユーザーは、プレースホルダユーザーからのコントリビュートとメンバーシップを既存のアクティブな（ボットではない）ユーザーに再割り当てできます。移行先インスタンスでは、トップレベルグループのオーナーロールを持つユーザーは、次のことができます:

• UIで、またはCSVファイルを介して、ユーザーにコントリビュートとメンバーシップの再アサインをレビューするようリクエストします。多数のプレースホルダーユーザーがいる場合は、CSVファイルを使用する必要があります。どちらの場合も、ユーザーは再アサインを受け入れるか拒否するためのリクエストをメールで受信します。選択したユーザーが再割り当てリクエストを承認した後にのみ、再割り当てが開始されます。
• コントリビュートとメンバーシップを再アサインしないことを選択し、プレースホルダーユーザーに割り当てられたままにします。

GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者は確認なしに、アクティブおよび非アクティブな非ボットユーザーにコントリビュートとメンバーシップをすぐに再割り当てできます。詳細については、管理者がプレースホルダーユーザーを再アサインするときに承認をスキップするを参照してください。

プレースホルダユーザーの再割り当て時に確認を回避する

前提要件:

• グループのオーナーロールを持っている必要があります。

プレースホルダを再割り当てる際に、エンタープライズユーザーの確認を回避するには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 設定 > 一般を選択します。
3. 権限とグループ機能を展開します。
4. プレースホルダーユーザーの確認で、プレースホルダーをユーザー認証なしにエンタープライズユーザーに再割り当てチェックボックスを選択します。
5. When to restore user confirmation（ユーザー確認を復元する時期） で、ユーザー確認を回避するための終了日を選択します。デフォルト値は1日です。
6. 変更を保存を選択します。

複数のプレースホルダーユーザーからのコントリビュートの再割り当て

最初に単一のプレースホルダーユーザーに割り当てられたすべてのコントリビュートは、移行先インスタンス上の単一のアクティブな標準ユーザーにのみ再アサインできます。単一のプレースホルダーユーザーに割り当てられたコントリビュートを、複数のアクティブな標準ユーザーに分割することはできません。

プレースホルダーユーザーが以下からのユーザーである場合、複数のプレースホルダーユーザーからのコントリビュートを宛先インスタンス上の同じユーザーに再アサインできます:

• 異なるソースインスタンス
• 同じソースインスタンス（宛先インスタンス上の異なるトップレベルグループにインポートされる）

割り当てられたユーザーが再アサインリクエストを承認する前に無効になった場合、保留中の再アサインは、ユーザーが承認するまでユーザーにリンクされたままになります。

移行元インスタンスのボットユーザーのコントリビュートとメンバーシップを、移行先インスタンスのボットユーザーに再アサインすることはできません。移行元のボットユーザーのコントリビュートをプレースホルダーユーザーに割り当てたままにすることができます。

再割り当てリクエストを受信するユーザーは、次のことができます:

• リクエストを承認する。以前にプレースホルダーユーザーに起因していたすべてのコントリビュートとメンバーシップは、承認ユーザーに再アサインされます。このプロセスには、コントリビュートの数に応じて数分かかる場合があります。
• リクエストを拒否するか、スパムとして報告します。このオプションは、再割り当てリクエストメールで利用できます。

同じトップレベルグループへの以降のインポートでは、同じソースユーザーに属するコントリビュートとメンバーシップは、そのソースユーザーの再アサインを以前に承認したユーザーに自動的にマッピングされます。

GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者は確認なしに、アクティブおよび非アクティブな非ボットユーザーにコントリビュートとメンバーシップをすぐに再割り当てできます。詳細については、管理者がプレースホルダーユーザーを再アサインするときに承認をスキップするを参照してください。

再アサインの完了

再アサインプロセスは、次の操作を行う前に完全に完了する必要があります:

• 同じGitLabインスタンス内でインポートされたグループを移動する。
• インポートされたプロジェクトを別のグループに移動する。
• インポートされたイシューを複製します。
• インポートされたイシューをエピックにプロモートします。

プロセスが完了していない場合、プレースホルダーユーザーに割り当てられたままのコントリビュートは、実際のユーザーに再アサインできず、プレースホルダーユーザーに関連付けられたままになります。

セキュリティに関する考慮事項

コントリビュートとメンバーシップの再アサインは元に戻すことができないため、開始する前にすべてを注意深く確認してください。

コントリビュートとメンバーシップを誤ったユーザーに再アサインすると、そのユーザーがグループのメンバーになるため、セキュリティ上の脅威となります。そのため、閲覧を許可されていない情報を閲覧できるようになります。

管理者アクセス権を持つユーザーへのコントリビュートの再アサインはデフォルトで無効になっていますが、有効にすることができます。

メンバーシップのセキュリティに関する考慮事項

GitLabの権限モデルにより、グループまたはプロジェクトが既存の親グループにインポートされると、親グループのメンバーには、インポートされたグループまたはプロジェクトの継承されたメンバーシップが付与されます。

インポートされたグループまたはプロジェクトの既存の継承されたメンバーシップをすでに持っているユーザーをコントリビュートとメンバーシップの再アサインに選択すると、メンバーシップがそのユーザーにどのように再アサインされるかに影響を与える可能性があります。

GitLabでは、子プロジェクトまたはグループのメンバーシップが、継承されたメンバーシップよりも低いロールを持つことは許可されていません。割り当てられたユーザーのインポートされたメンバーシップが、既存の継承されたメンバーシップよりも低いロールを持っている場合、インポートされたメンバーシップはユーザーに再アサインされません。

その結果、インポートされたグループまたはプロジェクトのメンバーシップが、移行元よりも高い状態になります。

UIで再割り当てをリクエストする

前提要件:

• グループのオーナーロールを持っている必要があります。

トップレベルグループでコントリビュートとメンバーシップを再割り当てできます。コントリビュートとメンバーシップの再割り当てをリクエストするには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。
4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
5. 各プレースホルダーについて、テーブルの列プレースホルダーユーザーとソースの情報をレビューします。
6. プレースホルダーの再割り当て先列で、ドロップダウンリストからユーザーを選択します。
7. 再割り当てするを選択します。

1つのプレースホルダーユーザーのコントリビュートのみを、移行先インスタンスのアクティブな非ボットユーザーに再アサインできます。

ユーザーが再アサインを承認する前に、リクエストをキャンセルできます。

GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者は確認なしに、アクティブおよび非アクティブな非ボットユーザーにコントリビュートとメンバーシップをすぐに再割り当てできます。詳細については、管理者がプレースホルダーユーザーを再アサインするときに承認をスキップするを参照してください。

CSVファイルを使用して再アサインをリクエストする

前提要件:

• グループのオーナーロールを持っている必要があります。

多数のプレースホルダーユーザーの場合、CSVファイルを使用してコントリビュートとメンバーシップを再アサインすることができます。次の情報を含む、事前入力されたCSVテンプレートをダウンロードできます。次に例を示します:

Source host（ソースホスト）、Import type（インポートタイプ）、またはSource user identifier（ソースユーザー識別子）を更新しないでください。この情報は、完成したCSVファイルをアップロードした後で、対応するデータベースレコードを見つけるために使用されます。Source user name（ソースユーザーの氏名）とSource username（ソースユーザー名）は、ソースユーザーを識別するものであり、CSVファイルをアップロードした後は使用されません。

CSVファイルのすべての行を更新する必要はありません。GitLabのユーザー名またはGitLab public email（GitLabパブリックメール）を含む行のみが処理されます。他のすべての行はスキップされます。

CSVファイルを使用してコントリビュートとメンバーシップの再アサインをリクエストするには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。
4. Reassign with CSV（CSVで再アサイン）を選択します。
5. 事前入力されたCSVテンプレートをダウンロードします。
6. GitLabのユーザー名またはGitLab public email（GitLabパブリックメール）に、移行先インスタンスのGitLabユーザーのユーザー名またはパブリックメールアドレスを入力します。インスタンス管理者は、確認済みのメールアドレスを持つユーザーを再割り当てできます。
7. 完成したCSVファイルをアップロードします。
8. 再割り当てするを選択します。

単一のプレースホルダーユーザーからのコントリビュートのみを、移行先インスタンスの各アクティブな非ボットユーザーに割り当てることができます。ユーザーは、自分に再アサインされたコントリビュートをレビューして承認するためのメールを受信します。ユーザーがレビューする前に、再アサインリクエストをキャンセルできます。

GitLab Self-ManagedおよびGitLab Dedicatedでは、管理者は確認なしに、アクティブおよび非アクティブな非ボットユーザーにコントリビュートとメンバーシップをすぐに再割り当てできます。詳細については、管理者がプレースホルダーユーザーを再アサインするときに承認をスキップするを参照してください。

コントリビュートを再アサインすると、GitLabから次の数が記載されたメールが送信されます:

• 正常に処理された行
• 正常に処理されなかった行
• スキップされた行

正常に処理されなかった行がある場合、メールには、より詳細な結果が記載されたCSVファイルが添付されます。

UIを使用せずにプレースホルダーユーザーを一括で再割り当てするには、グループプレースホルダー再割り当てAPIを参照してください。

プレースホルダーとして保持する

コントリビュートとメンバーシップを移行先インスタンスのユーザーに再アサインしたくない場合があります。たとえば、移行元インスタンスでコントリビュートした元従業員がいて、移行先インスタンスにユーザーとして存在しない場合があります。

このような場合は、コントリビュートをプレースホルダーユーザーに割り当てたままにすることができます。プレースホルダーユーザーは、プロジェクトまたはグループのメンバーになることができないため、メンバーシップ情報を保持しません。

プレースホルダーユーザーの名前とユーザー名は、移行元ユーザーの名前とユーザー名に似ているため、多くの履歴コンテキストを保持できます。

コントリビュートをプレースホルダーユーザーに割り当てたままにすることは、一度に1つずつ行うか、一括で行うことができます。コントリビュートを一括で再アサインすると、ネームスペース全体と、次の再アサインステータスを持つユーザーが影響を受けます:

• Not started
• Rejected

プレースホルダーユーザーを一度に1つずつ保持するには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。
4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
5. プレースホルダーユーザーおよびソース列をレビューして、保持するプレースホルダーユーザーを見つけます。
6. プレースホルダーの再割り当て先列で、再割り当てしないを選択します。
7. 確認を選択します。

プレースホルダーユーザーを一括で保持するには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。
4. リストの上にある縦方向の省略記号（ ）> すべてをプレースホルダーとして保持を選択します。
5. 確認ダイアログで、確認を選択します。

操作を元に復元するには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。
4. 再割り当て済サブタブに移動します。このサブタブでは、プレースホルダが表形式で表示されます。
5. 適切な行で元に戻すを選択します。

再割り当てのリクエストをキャンセルする

ユーザーが再割り当てリクエストを承認する前に、リクエストをキャンセルできます:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。
4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
5. 正しい行でキャンセルを選択します。

保留中の再割り当てリクエストについて、再度ユーザーに通知する

ユーザーが再アサインリクエストに対応していない場合は、別のメールを送信して再度プロンプトを表示できます:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。
4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
5. 正しい行でNotify（通知）を選択します。

再アサインステータスで表示およびフィルタリングする

すべてのプレースホルダーユーザーの再アサインステータスを表示するには:

1. 左側のサイドバーで、検索または移動先を選択して、グループを見つけます。このグループはトップレベルにある必要があります。
2. 管理 > メンバーを選択します。
3. プレースホルダータブを選択します。
4. 再割り当て待ちサブタブに移動します。プレースホルダーがテーブルにリストされています。
5. 再割り当てのステータス列で、各プレースホルダーユーザーの状態を確認します。

再割り当て待ちタブで使用可能なステータスは次のとおりです:

• Not started - 再アサインは開始されていません。
• Pending approval - 再アサインは、ユーザーの承認を待機しています。
• Reassigning - 再アサインが進行中です。
• Rejected - 再アサインはユーザーによって拒否されました。
• Failed - 再アサインに失敗しました。

再割り当て済タブで使用可能なステータスは次のとおりです:

• Success - 再アサインに成功しました。
• Kept as placeholder - プレースホルダーユーザーが永続化されました。

デフォルトでは、テーブルはプレースホルダーユーザー名でアルファベット順に並べ替えられています。再アサイン状態でテーブルを並べ替えることもできます。

コントリビュートの再割り当てを確認する

Skip confirmation when administrators reassign placeholder users（管理者がプレースホルダーユーザーを再割り当てするときに承認をスキップする）が有効になっている場合:

• 管理者はユーザーの承認なしに、コントリビュートをすぐに再アサインできます。
• 管理者は、アクティブおよび非アクティブな非ボットユーザーにコントリビュートを再割り当てることができます。
• コントリビュートが再割り当てされたことを通知するメールが届きます。

この設定が有効になっていない場合、再アサインを承認または却下できます。

コントリビュートの再割り当てを承認する

インポート処理が行われたことを知らせるメールが届き、コントリビュートを自分自身に再アサインすることを確認するように求められる場合があります。

このインポート処理について知らされた場合でも、再アサインの詳細を非常に注意深くレビューする必要があります。メールに記載されている詳細は次のとおりです:

• Imported from（インポート元） - インポートされたコンテンツの送信元プラットフォーム。たとえば、GitLab、GitHub、またはBitbucketの別のインスタンス。
• Original user（元のユーザー） - ソースプラットフォーム上のユーザーの氏名とユーザー名。これは、そのプラットフォームでのあなたの氏名とユーザー名である可能性があります。
• Imported to（インポート先） - 新しいプラットフォームの名前。GitLabインスタンスのみです。
• 再割り当てした先: - GitLabインスタンスでのあなたの氏名とユーザー名。
• Reassigned by（再アサイン者） - インポートを実行した同僚または上司の氏名とユーザー名。

コントリビュートの再割り当てを拒否する

コントリビュートの自分自身への再アサインを確認するように求めるメールを受信し、この情報を認識しない場合、または誤りに気付いた場合は、次のようにします:

1. まったく続行しないでください。または、コントリビュートの再アサインを拒否してください。
2. 信頼できる同僚または上司に相談してください。

セキュリティに関する考慮事項

再割り当てリクエストの再アサインの詳細を非常に注意深くレビューする必要があります。信頼できる同僚または上司からこのプロセスについて事前に知らされていない場合は、特に注意してください。

疑わしい再割り当てを承認するのではなく、次のようにします:

1. メールに対応しないでください。
2. 信頼できる同僚または上司に相談してください。

知っていて信頼できるユーザーからの再アサインのみを承認してください。コントリビュートの再アサインは永続的であり、元に戻すことはできません。再割り当てを承認すると、コントリビュートが誤ってあなたに起因する可能性があります。

コントリビュートの再アサインプロセスは、GitLabで再割り当てを承認するを選択して再アサインリクエストを承認した後にのみ開始されます。プロセスは、メール内のリンクを選択しても開始されません。

プロジェクトインポートの履歴を表示する

自分で作成したすべてのプロジェクトインポートを表示できます。このリストには、次のものが含まれています:

• プロジェクトが外部システムからインポートされた場合はソースプロジェクトのパス、またはGitLabプロジェクトが移行された場合はインポート方法。
• 移行先プロジェクトのパス。
• 各インポートの開始日。
• 各インポートの状態。
• エラーが発生した場合のエラーの詳細。

プロジェクトのインポート履歴を表示するには:

1. GitLabにサインインします。
2. 左側のサイドバーの上部にある新規作成（ ）と新規プロジェクト/リポジトリを選択します。
3. プロジェクトのインポートを選択します。
4. 右上隅にある履歴リンクを選択します。
5. 特定のインポートにエラーがある場合は、詳細を選択して表示します。

履歴には、組み込みまたはカスタムテンプレートから作成されたプロジェクトも含まれています。GitLabはURLでリポジトリをインポートして、テンプレートから新しいプロジェクトを作成します。

LFSオブジェクトを含むプロジェクトをインポートする

LFSオブジェクトを含むプロジェクトをインポートする場合、プロジェクトにリポジトリURLホストとは異なるURLホスト（lfs.url）を持つ.lfsconfigファイルがある場合、LFSファイルはダウンロードされません。

プロフェッショナルサービスを利用して移行する

自分で移行する代わりに、GitLabプロフェッショナルサービスを利用してグループとプロジェクトをGitLabに移行することもできます。詳しくは、GitLabプロフェッショナルサービスフルカタログをご覧ください。

Sidekiqの設定

インポーターは、グループとプロジェクトのインポートおよびエクスポートを処理するために、Sidekiqジョブに大きく依存しています。これらのジョブの中には、大量のリソース（CPUとメモリ）を消費し、完了までに長い時間がかかるものがあり、他のジョブの実行に影響を与える可能性があります。このイシューを解決するには、インポータージョブを専任のSidekiqキューにルーティングし、そのキューを処理するために専任のSidekiqプロセスを割り当てる必要があります。

たとえば、次の設定を使用できます:

sidekiq['concurrency'] = 20

sidekiq['routing_rules'] = [
  # Route import and export jobs to the importer queue
  ['feature_category=importers', 'importers'],

  # Route all other jobs to the default queue by using wildcard matching
  ['*', 'default']
]

sidekiq['queue_groups'] = [
  # Run a dedicated process for the importer queue
  'importers',

  # Run a separate process for the default and mailer queues
  'default,mailers'
]

この設定では、次のようになります:

• 専任のSidekiqプロセスは、インポーターキューを介してインポートおよびエクスポートジョブを処理します。
• 別のSidekiqプロセスは、他のすべてのジョブ（デフォルトキューとメーラーキュー）を処理します。
• 両方のSidekiqプロセスは、デフォルトで20スレッドの同時実行をするように設定されています。メモリが制約された環境では、この数値を減らすことをお勧めします。

インスタンスに、より多くの同時ジョブをサポートするのに十分なリソースがある場合は、追加のSidekiqプロセスを設定して、移行を高速化できます。次に例を示します:

sidekiq['queue_groups'] = [
  # Run three processes for importer jobs
  'importers',
  'importers',
  'importers',

  # Run a separate process for the default and mailer queues
  'default,mailers'
]

この設定では、複数のSidekiqプロセスがインポートおよびエクスポートジョブを同時に処理するため、インスタンスに十分なリソースがある限り、移行が高速化されます。

Sidekiqプロセスの最大数については、次の点に注意してください:

• プロセスの数は、使用可能なCPUコアの数を超えないようにする必要があります。
• 各プロセスは最大2 GiBのメモリを使用する可能性があるため、インスタンスに追加のプロセスに対応できる十分なメモリがあることを確認してください。
• 各プロセスは、sidekiq['concurrency']で定義されているように、スレッドごとに1つのデータベース接続を追加します。

詳細については、複数のSidekiqプロセスの実行および特定のジョブクラスの処理を参照してください。

トラブルシューティング

インポートされたリポジトリにブランチがない

インポートされたリポジトリにソースリポジトリのすべてのブランチが含まれていない場合:

1. 環境変数IMPORT_DEBUG=trueを設定します。
2. 別のグループ、サブグループ、またはプロジェクト名を使用してインポートを再試行します。
3. 一部のブランチがまだ見つからない場合は、importer.log （たとえば、jqを使用）を調べます。

例外: Error Importing repository - No such file or directory @ rb_sysopen - (filename)

このエラーは、リポジトリのソースコードのtar.gzファイルダウンロードをインポートしようとすると発生します。

インポートには、単なるリポジトリのダウンロードファイルではなく、GitLabエクスポートファイルが必要です。

長期化または失敗したインポートを診断する

ファイルベースのインポート（特にS3を使用するインポート）で長期の遅延やエラーが発生している場合は、次の方法で問題の根本原因を特定できる可能性があります:

• インポート手順の確認
• ログのレビュー
• 一般的なイシューの特定

インポート状態を確認する

インポート状態を確認します:

1. GitLab APIを使用して、影響を受けるプロジェクトのインポート状態を確認します。
2. 特にstatus値とimport_error値について、エラーメッセージまたは状態情報に対する応答をレビューします。
3. 応答のcorrelation_idに注意してください。これは、さらなるトラブルシューティングに不可欠です。

ログをレビューする

関連情報についてログを検索します:

GitLab Self-Managedインスタンスの場合:

1. Sidekiqログとexceptions_jsonログを確認します。
2. RepositoryImportWorkerおよびインポート状態の確認からの相関IDに関連するエントリを検索します。
3. job_status、interrupted_count、exceptionなどのフィールドを探します。

GitLab.comの場合（GitLabチームメンバーのみ）:

1. Kibanaを使用して、次のようなクエリでSidekiqログを検索します:

   ターゲット: pubsub-sidekiq-inf-gprd*

   json.class: "RepositoryImportWorker" AND json.correlation_id.keyword: "<CORRELATION_ID>"

   または

   json.class: "RepositoryImportWorker" AND json.meta.project: "<project.full_path>"

2. GitLab Self-Managedインスタンスについて言及されているのと同じフィールドを探します。

共通のイシューを特定する

ログのレビューで収集した情報を、次の一般的なイシューと照らし合わせてレビューします:

• 中断されたジョブ: 失敗を示す高いinterrupted_countまたはjob_statusが表示された場合、インポートジョブが複数回中断され、デッドキューに配置された可能性があります。
• S3接続: S3を使用するインポートの場合は、ログでS3関連のエラーメッセージを確認してください。
• 大きなリポジトリ: リポジトリが非常に大きい場合、インポートがタイムアウトになる可能性があります。この場合は、直接転送の使用を検討してください。