GitHubリポジトリを自社組織から他社(顧客)の組織へ移す際、単にコードを複製するだけでなく、IssueやPull Requestの履歴も丸ごと引き継ぎたいケースがあります。その場合に便利なのが、GitHubの「Transfer(移譲)」機能です。

ご注意:本記事は2025年4月時点での移行経験に基づき作成しています。GitHubの仕様やUIは頻繁にアップデートされるため、実際に作業を行う際は必ずGitHub公式ドキュメントの最新情報を併せてご確認ください。

1. 移行方法の選定:Transfer vs Clone & Push

リポジトリを移行する方法はいくつかありますが、プロジェクトの過程を保存したい場合は、管理画面からの移譲が最適です。

  • Transfer(移譲): Issue、PR、Wiki、Projects、リリース等の全データを引き継ぎます。古いURLからの自動リダイレクトも設定されるため、スムーズな移行が可能です。
  • Clone & Push(複製): ソースコードとコミット履歴のみを移行します。GitHub固有のデータ(Issue等)を破棄し、中身をクリーンにして始めたい場合に適しています。

※「Transfer」が使えるのは、オンプレミス環境(GHES)同士、クラウド版同士など、同じプラットフォーム内にリポジトリを移動させる場合のみです。

2. 事前準備と確認事項

移譲作業を始める前に、以下の準備ができているか確認しましょう。

権限の確認

移譲作業担当者は、以下の両方の権限を持っている必要があります。

  • 移行元:対象リポジトリの管理者(Admin)権限。
  • 移行先:組織のメンバーであり、かつ「リポジトリを作成する権限」を持っていること。

移譲先組織のSSO認証

移行先の組織でSAMLシングルサインオン(SSO)が有効な場合、事前にその組織のリソース(リポジトリ一覧など)にアクセスし、SSO認証を済ませておいてください。この認証が済んでいないと、移譲先の候補に組織名が表示されないという現象が発生します。

コラボレーターのクリーンアップ

移行が完了すると、元のリポジトリに紐付いていたコラボレーターは、移行先組織に「Outside Collaborator」として自動登録されます。これは移行先のライセンス(課金対象)を消費する原因となるため、継続してアクセスする必要がないメンバーは、移行前に削除しておくことを推奨します。
※コラボレーターを削除しても、過去のコミット履歴や名前が消えることはありません。

移行先プランの確認

クラウド版の場合、移行先がGitHub Team以上の有料プラン(GiHub Team、GiHub Enterprise Cloud)であることを確認。FreeプランだとPrivateリポジトリの一部機能が制限されます。

名前の重複がないかを確認

移行先の組織に、同名のリポジトリやフォークが存在しないことを確認。

3. 移譲作業の手順

ステップ1:直前バックアップ

万が一の事態に備え、手元にミラークローンを作成しておくと安心です。

ステップ2:移譲の実行

  1. 移行先組織のSSO認証を済ませた上で、移行元リポジトリの [Settings] タブを開きます。
  2. 一番下の [Danger Zone] セクションにある [Transfer] をクリックします。
  3. 新しい所有者(New owner)として、移行先の組織名を入力します。※この選択肢に組織名が出てこない場合は組織にSSOサインインできていない可能性があります。ここで誤って個人を選んでしまわないよう気を付けてください。
  4. 表示される警告メッセージを確認し、最終確認のためリポジトリ名をテキストボックスに入力して実行します。

4. 移行後の設定作業

移譲が完了したら、速やかに以下の設定を確認・実施しましょう。

  1. メンバーの整理:移行先の担当者をリポジトリの「Admin」権限に昇格させます。移行されたコラボレーターの権限を適したものに変更します。不要なコラボレーターを削除します。
  2. 公開範囲の確認:意図せず「Public」になっていないか、改めて Visibility を確認します。
  3. 外部連携の修正:
    • GitHub Actions のワークフロー内のパス指定の確認
    • Webhook(Slack通知など)の再設定
    • CI/CDツール(AWS, Vercelなど)との再連携
  4. ローカル環境の更新:開発メンバーにリモートURLの更新を依頼します。

5. 最後に:テストリポジトリでの「リハーサル」がおすすめ

GitHubの設定や権限は多岐にわたるため、本番リポジトリの移行前に、テスト用の空リポジトリで移譲プロセスを試行することをおすすめします。
私も実際にテストリポジトリを作成し、「Privateリポジトリが公開されてしまわないか」等、事前検証しました。お客様と一緒にテストできたため、お互いに安心感を持って本番作業に臨むことができました。
「間違いが許されない作業」だからこそ、こうした事前のリハーサルが最大の成功の鍵となります。今後リポジトリの譲渡を予定されている方の参考になれば幸いです。