{"meta":{"title":"GitHub Enterprise Server へのデータの移行","intro":"移行アーカイブを生成した後、ターゲット GitHub Enterprise Server インスタンスにデータをインポートできます。 変更を恒久的にターゲットのインスタンスに適用する前に、潜在的なコンフリクトがないか変更をレビューできます。","product":"移行","breadcrumbs":[{"href":"/ja/migrations","title":"移行"},{"href":"/ja/migrations/using-ghe-migrator","title":"ghe-migrator"},{"href":"/ja/migrations/using-ghe-migrator/migrating-data-to-github-enterprise-server","title":"データの移行"}],"documentType":"article"},"body":"# GitHub Enterprise Server へのデータの移行\n\n移行アーカイブを生成した後、ターゲット GitHub Enterprise Server インスタンスにデータをインポートできます。 変更を恒久的にターゲットのインスタンスに適用する前に、潜在的なコンフリクトがないか変更をレビューできます。\n\n## 移行データの準備\n\n1. [\n   `scp`\n   ](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) コマンドを使用して、ソース インスタンスまたは組織から生成された移行アーカイブをGitHub Enterprise Serverターゲットにコピーします。\n\n   ```shell\n   scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/\n   ```\n\n2. ターゲット GitHub Enterprise Server インスタンスに SSH 接続します。 詳しくは、「[管理シェル (SSH) にアクセスする](/ja/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)」をご覧ください。\n\n   ```shell\n   ssh -p 122 admin@HOSTNAME\n   ```\n\n3. 移行アーカイブに十分な読み取りアクセス許可があることを確認します。\n\n   ```shell\n   chmod 644 /home/admin/MIGRATION-GUID.tar.gz\n   ```\n\n4. `ghe-migrator prepare` コマンドを使ってターゲット インスタンスにインポートするためのアーカイブを準備し、以降の手順で使用する新しい移行 GUID を生成します。\n\n   ```shell\n   ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz\n   ```\n\n   * 新しいインポートの試行を開始するには、もう一度 `ghe-migrator prepare` を実行し、新しい移行 GUID を取得します。\n   * 移行ファイルをステージングする場所を指定するには、`--staging-path=/full/staging/path` を使用してコマンドを追加します。 既定値は `/data/user/tmp` です。\n\n## 移行のコンフリクトのリストの生成\n\n1. 移行 GUID を指定した `ghe-migrator conflicts` コマンドを使用して、*conflicts.csv* ファイルを生成します。\n\n   ```shell\n   ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv\n   ```\n\n   * 競合が報告されない場合、データを安全にインポートできます。\n\n2. 競合がある場合は、[`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) コマンドを使用して、*conflicts.csv* をローカル コンピューターにコピーします。\n\n   ```shell\n   scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop\n   ```\n\n3. 「[移行コンフリクトの解決もしくはカスタム マッピングのセットアップ](#resolving-migration-conflicts-or-setting-up-custom-mappings)」に進みます。\n\n## 移行コンフリクトのレビュー\n\n1. テキスト エディターまたは [CSV 互換のスプレッドシート ソフトウェア](https://en.wikipedia.org/wiki/Comma-separated_values#Application_support)を使用して、*conflicts.csv* を開きます。\n2. 以下の例と参照表のガイダンスを使用して、*conflicts.csv* ファイルを確認し、確実にインポート時に適切なアクションが実行されるようにします。\n\n*conflicts.csv* ファイルには、競合の ''*移行マップ*'' と推奨アクションが含まれています。 移行マップは、ソースから移行されるデータと、そのデータがどのようにターゲットに適用されるかのリストです。\n\n| `model_name`   | `source_url`                                           | `target_url`                                           | `recommended_action` |\n| -------------- | ------------------------------------------------------ | ------------------------------------------------------ | -------------------- |\n| `user`         | `https://example-gh.source/octocat`                    | `https://example-gh.target/octocat`                    | `map`                |\n| `organization` | `https://example-gh.source/octo-org`                   | `https://example-gh.target/octo-org`                   | `map`                |\n| `repository`   | `https://example-gh.source/octo-org/widgets`           | `https://example-gh.target/octo-org/widgets`           | `rename`             |\n| `team`         | `https://example-gh.source/orgs/octo-org/teams/admins` | `https://example-gh.target/orgs/octo-org/teams/admins` | `merge`              |\n\n*conflicts.csv* の各行には次の情報が示されます。\n\n| 名前                   | 説明                                            |\n| -------------------- | --------------------------------------------- |\n| `model_name`         | 変更されるデータの種類。                                  |\n| `source_url`         | データのソースURL。                                   |\n| `target_url`         | 期待されるデータのターゲットURL。                            |\n| `recommended_action` | データのインポート時に推奨されるアクション `ghe-migrator` が実行されます。 |\n\n### 各レコードタイプで可能なマッピング\n\nデータの転送時に `ghe-migrator` で実行できるいくつかの異なるマッピング アクションがあります。\n\n| `action`        | 説明                                                                                                                     | 適用可能なモデル                         |\n| --------------- | ---------------------------------------------------------------------------------------------------------------------- | -------------------------------- |\n| `import`        | （デフォルト）ソースからのデータがターゲットにインポートされます。                                                                                      | すべてのレコードタイプ                      |\n| `map`           | ソース データに基づいて新しいモデルを作成する代わりに、ターゲット内の既存のレコードが使用されます。 リポジトリを既存の組織にインポートしたり、ターゲットのユーザー ID をソースのユーザー ID にマッピングしたりする場合に便利です。 | ユーザー、組織                          |\n| `rename`        | ソースからのデータは名前が変更されてターゲットにコピーされます。                                                                                       | Users、organizations、repositories |\n| `map_or_rename` | ターゲットが存在する場合、そのターゲットにマップします。 そうでない場合はインポートされたモデルの名前を変更します。                                                             | ユーザー                             |\n| `merge`         | ソースからのデータはターゲット上の既存のデータと組み合わされます。                                                                                      | Teams                            |\n\n\\*\\*\n*conflicts.csv* ファイルを確認し、`ghe-migrator audit` を使用して、確実に適切なアクションが実行されるようにすることを強くお勧めします。\\*\\* すべてが良好な場合、続行できます。\n\n## 移行コンフリクトの解決もしくはカスタムマッピングのセットアップ\n\n`ghe-migrator` で正しくない変更が行われると思われる場合は、*conflicts.csv* 内でデータを変更することによって修正できます。\n*conflicts.csv* 内の任意の行を変更できます。\n\nたとえば、ソースの `octocat` ユーザーがターゲットの `octocat` にマップされていることに気付いたとしましょう。\n\n| `model_name` | `source_url`                        | `target_url`                        | `recommended_action` |\n| ------------ | ----------------------------------- | ----------------------------------- | -------------------- |\n| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/octocat` | `map`                |\n\nこのユーザをターゲット上の他のユーザにマップさせることができます。\n`octocat` が実際にはターゲットの `monalisa` であるべきだとわかっているとします。\n`target_url` の \\_\\_ 列を `monalisa` を参照するように変更することができます。\n\n| `model_name` | `source_url`                        | `target_url`                         | `recommended_action` |\n| ------------ | ----------------------------------- | ------------------------------------ | -------------------- |\n| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `map`                |\n\n別の例として、`octo-org/widgets` リポジトリの名前をターゲット インスタンスの `octo-org/amazing-widgets` に変更する場合は、`target_url` を `octo-org/amazing-widgets`、および `recommend_action` を `rename` に変更します。\n\n| `model_name` | `source_url`                                 | `target_url`                                         | `recommended_action` |\n| ------------ | -------------------------------------------- | ---------------------------------------------------- | -------------------- |\n| `repository` | `https://example-gh.source/octo-org/widgets` | `https://example-gh.target/octo-org/amazing-widgets` | `rename`             |\n\n### カスタムマッピングの追加\n\n移行における一般的なシナリオは、移行されたユーザがターゲット上ではソース上とは異なるユーザ名を持つことです。\n\nソースのユーザ名のリストとターゲットのユーザー名のリストがあれば、カスタムマッピングのCSVファイルを構築し、各ユーザのユーザ名とコンテンツが移行の終了時点で正しく割り当てられているようにそのファイルを適用できます。\n\n`ghe-migrator audit` コマンドを使用して、カスタム マッピングを適用するために必要な CSV 形式で、移行されるユーザーの CSV をすばやく生成できます。\n\n```shell\nghe-migrator audit -m user -g MIGRATION-GUID > users.csv\n```\n\nこれで、その CSV を編集し、マップまたは名前を変更する各ユーザーの新しい URL を入力してから、4 番目の列を更新し、適宜、`map` または `rename` が含まれるようにすることができます。\n\nたとえば、ユーザー `octocat` の名前をターゲット `monalisa` の `https://example-gh.target` に変更するには、次の内容の行を作成します。\n\n| `model_name` | `source_url`                        | `target_url`                         | `state`  |\n| ------------ | ----------------------------------- | ------------------------------------ | -------- |\n| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `rename` |\n\n同じプロセスは、カスタムマッピングをサポートする各レコードのマッピングを作成するために使うことができます。 詳細については、[レコードで可能なマッピングに関する表](#possible-mappings-for-each-record-type)を参照してください。\n\n### 修正された移行データの適用\n\n1. 変更を行った後、[`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) コマンドを使用して、変更した *conflicts.csv* (または正しい形式の他のマッピング *.csv* ファイル) をターゲット インスタンスに適用します。\n\n   ```shell\n   scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/\n   ```\n\n2. `ghe-migrator map` コマンドを使用して移行データを再マップし、変更した *.csv* ファイルと移行 GUID へのパスを渡します。\n\n   ```shell\n   ghe-migrator map -i conflicts.csv -g MIGRATION-GUID\n   ```\n\n3. `ghe-migrator map -i conflicts.csv -g MIGRATION-GUID` コマンドで競合がまだ存在することが報告された場合は、移行の競合解決プロセスをもう一度実行します。\n\n## GitHub Enterprise Server にインポートしたデータを適用\n\n1. ターゲット GitHub Enterprise Server インスタンスに SSH 接続します。 詳しくは、「[管理シェル (SSH) にアクセスする](/ja/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)」をご覧ください。\n\n   ```shell\n   ssh -p 122 admin@HOSTNAME\n   ```\n\n2. `ghe-migrator import` コマンドを使用して、インポート プロセスを開始します。 必要なものは次のとおりです。\n\n   * 移行 GUID。 詳細については、[移行されたデータをGitHub Enterprise Serverにインポートするための準備を](#preparing-the-migrated-data)参照してください。\n   * 認証の対象とする personal access token。 使用する personal access token はサイト管理者としての認証専用であり、特定のスコープやアクセス許可は必要ありません。 詳しくは、「[個人用アクセス トークンを管理する](/ja/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens)」をご覧ください。\n\n   ```shell\n   $ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN\n\n   > Starting GitHub::Migrator\n   > Import 100% complete /\n   ```\n\n   * 移行ファイルをステージングする場所を指定するには、`--staging-path=/full/staging/path` を使用してコマンドを追加します。 既定値は `/data/user/tmp` です。\n\n## 移行データのレビュー\n\n既定では、`ghe-migrator audit` はすべてのレコードを返します。 また、以下の条件でレコードをフィルタリングすることもできます。\n\n* レコードのタイプ。\n* レコードの状態。\n\nレコードの種類は、[移行されたデータ](/ja/migrations/using-ghe-migrator/about-ghe-migrator#migrated-data)で見つかったものと一致します。\n\n## レコードタイプのフィルタ\n\n| レコード タイプ                    | フィルター名                        |\n| --------------------------- | ----------------------------- |\n| ユーザー                        | `user`                        |\n| 組織                          | `organization`                |\n| リポジトリ                       | `repository`                  |\n| Teams                       | `team`                        |\n| マイルストーン                     | `milestone`                   |\n| 問題                          | `issue`                       |\n| Issueのコメント                  | `issue_comment`               |\n| Pull Request                | `pull_request`                |\n| プルリクエストのレビュー                | `pull_request_review`         |\n| コミットコメント                    | `commit_comment`              |\n| プルリクエストのレビューのコメント           | `pull_request_review_comment` |\n| リリース                        | `release`                     |\n| プルリクエストまたはイシューに対して取られたアクション | `issue_event`                 |\n| 保護されたブランチ                   | `protected_branch`            |\n\n## レコードの状態フィルタ\n\n| レコードの状態         | 説明                  |\n| --------------- | ------------------- |\n| `export`        | レコードはエクスポートされます。    |\n| `import`        | レコードはインポートされます。     |\n| `map`           | レコードはマップされます。       |\n| `rename`        | レコードの名前が変更されます。     |\n| `merge`         | レコードは統合されます。        |\n| `exported`      | レコードはエクスポートに成功しました。 |\n| `imported`      | レコードはインポートに成功しました。  |\n| `mapped`        | レコードのマッピングが成功しました。  |\n| `renamed`       | レコードの名前の変更に成功しました。  |\n| `merged`        | レコードは正常に統合されました。    |\n| `failed_export` | レコードはエクスポートに失敗しました。 |\n| `failed_import` | レコードはインポートに失敗しました。  |\n| `failed_map`    | レコードはマップに失敗しました。    |\n| `failed_rename` | レコードの名前の変更に失敗しました。  |\n| `failed_merge`  | レコードはマージに失敗しました。    |\n\n## 監査されたレコードのフィルタリング\n\n`ghe-migrator audit` コマンドを使用すると、`-m` フラグを使用してレコードの種類に基づいてフィルター処理できます。 同様に、`-s` フラグを使用してインポート状態をフィルター処理できます。 次のようなコマンドです。\n\n```shell\nghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID\n```\n\nたとえば、インポートに成功したすべての組織とチームを見るには以下のようにします。\n\n```shell\n$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID\n> model_name,source_url,target_url,state\n> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed\n```\n\n**失敗したすべてのインポートを監査することを強くお勧めします。** これを行うには、次のように入力します。\n\n```shell\n$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID\n> model_name,source_url,target_url,state\n> user,https://gh.source/octocat,https://gh.target/octocat,failed\n> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed\n```\n\nインポートの失敗についてご不明な場合は、 [GitHub Enterprise サポート](https://support.github.com)にお問い合わせください。\n\n## GitHub Enterprise Server でのインポートを完了する\n\nターゲットインスタンスへの移行が適用され、その内容を確認したら、リポジトリのロックを解除して、ソースから削除します。 ソースデータを削除する前に、すべてが期待どおりに機能していることを確認するため2週間ほど待つことをおすすめします。\n\n## ターゲットインスタンス上でのリポジトリのアンロック\n\n1. GitHub.comに SSH 接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「[管理シェル (SSH) にアクセスする](/ja/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)」をご覧ください。\n\n   ```shell copy\n   ssh -p 122 admin@HOSTNAME\n   ```\n2. `ghe-migrator unlock` コマンドを使用して、インポートされたすべてのリポジトリのロックを解除します。 移行GUIDが必要になります。\n\n```shell\n$ ghe-migrator unlock -g MIGRATION-GUID\n> Unlocked octo-org/octo-project\n```\n\n> \\[!WARNING]\n> GitHub Actions トリガーを使用する`schedule`ワークフローがリポジトリに含まれている場合、ワークフローはインポート後に自動的に実行されません。 スケジュールされたワークフローをもう一度開始するには、リポジトリにコミットをプッシュします。 詳しくは、「[ワークフローをトリガーするイベント](/ja/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule)」をご覧ください。\n\n## ソース上でのリポジトリのアンロック\n\n移行が完了したら、ソースのリポジトリのロックを解除する必要があります。\n\n### GitHub.com 上の組織のリポジトリのロックを解除する\n\nGitHub.com組織のリポジトリのロックを解除するには、`DELETE`に[](/ja/rest/migrations#unlock-an-organization-repository)要求を送信します。 必要なものは次のとおりです。\n\n* 認証のためのアクセストークン\n* 移行の一意の `id`\n* アンロックするリポジトリの名前\n\n```shell\ncurl -H \"Authorization: Bearer GITHUB_ACCESS_TOKEN\" -X DELETE \\\n  -H \"Accept: application/vnd.github.wyandotte-preview+json\" \\\n  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock\n```\n\n### 組織からリポジトリを削除する GitHub.com\n\nGitHub.com組織のリポジトリのロックを解除した後、リポジトリ削除エンドポイントを使用して、以前に移行したすべての[リポジトリを削除](/ja/rest/repos/repos#delete-a-repository)する必要があります。 認証のためのアクセストークンが必要になります。\n\n```shell\ncurl -H \"Authorization: Bearer GITHUB_ACCESS_TOKEN\" -X DELETE \\\n  https://api.github.com/repos/ORG-NAME/REPO_NAME\n```\n\n### GitHub Enterprise Server インスタンスからのリポジトリのロック解除\n\n1. GitHub.comに SSH 接続します。 インスタンスが複数のノードで構成されている場合は (高可用性や geo レプリケーションが構成されている場合など)、プライマリ ノードに SSH 接続します。 クラスターを使用する場合は、任意のノードに SSH 接続できます。 HOSTNAME をインスタンスのホスト名、またはノードのホスト名または IP アドレスに置き換えます。 詳しくは、「[管理シェル (SSH) にアクセスする](/ja/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)」をご覧ください。\n\n   ```shell copy\n   ssh -p 122 admin@HOSTNAME\n   ```\n2. `ghe-migrator unlock` コマンドを使用して、インポートされたすべてのリポジトリのロックを解除します。 移行GUIDが必要になります。\n\n```shell\n$ ghe-migrator unlock -g MIGRATION-GUID\n> Unlocked octo-org/octo-project\n```"}