GitHub Organization間でRepositoryを移譲(Transfer)した際の情報の引き継ぎを確認してみた

結論:連携しているCIサービス側の紐付け含めどの情報も凄くよしなに移譲してくれる。
2020.06.12

こんにちは、CX事業本部の若槻です。

GitHubでは、Repositoryを別のUserやOrganizationアカウントに移譲(Transfer)することが可能です。次の公式ドキュメントを読む限りでは移譲機能を使えばRepository上の情報はほぼ全てをよしなに引き継いでくれるとのことです。

そこで今回は、GitHub Organization間でRepositoryを移譲(Transfer)した際に本当にRepository上の情報がちゃんと引き継がれるのか?を確認してみました。

事前準備

移譲実施前に次の準備を行いました。

  • 移譲先Orgに移譲元Orgのメンバーを所属させておく。
  • 移譲作業用アカウントを移譲先・移譲元OrgのOwnerにしておく。

引き継ぎ動作を確認するための情報の仕込み

Repositoryが移譲された際の引き継ぎ動作を確認するために、次の情報を移譲前のRepositoryに対して仕込みました。

  • commit、branch、Pull request 82c0dcde-a2fd-472a-bc53-91bbba9499c9.png

  • pacakge 6afa9ac3-8a2a-416f-ae72-838468d758fd.png

  • release 74fae5b2-4180-4d9a-b0a1-1e9828f2557f.png

  • Issue 1be372a1-c80c-46db-9870-882080390d81.png

  • Project スクリーンショット 2020-06-11 21.16.31.png

  • Secret e40989b3-65e7-423b-bffe-43c98b9ba42b.png

  • アクセス権限(有料プランのユーザー数が足りなかったため2回に分けて検証した)

    • ユーザーに直接付与されたアクセス権限 スクリーンショット 2020-06-11 21.46.16.png
    • Teamを介して付与されたアクセス権限 スクリーンショット 2020-06-11 21.34.23.png スクリーンショット 2020-06-11 21.35.19.png
  • Actionsの実行履歴 579f23c4-033e-41ac-b93e-4078a94123dc.png

  • Circleのプロジェクト、CI実行履歴 2bf6c32c-48b1-42dd-a8d7-e1018ef15bc2.png

  • TravisCIのCI実行履歴 d2a2ef2b-3a94-4a10-ab72-dbe402058f7d.png

  • BitriseのApp、CI実行履歴 image.png

移譲の実施

GitHubのコンソールから先ほど情報を仕込んだRepositoryの移譲を実施します。

移譲元のOrganizationでRepositoryの[Settings]タブ - [Options] - [Danger Zone]欄にて[Transfer]をクリック。 7038c2f9-2e06-40e5-908a-6044d32cd43c.png

移譲先のOrganization名と移譲するRepository名を入力し、[I understand, transfer this repository.]をクリック。 スクリーンショット 2020-06-11 21.21.36.png

※上記画面では移譲元のアカウントが有料プランなので、移譲先アカウントがFreeプランの場合に失われる情報についての警告が移譲ダイアログ内に記載されています。一方で移譲元のアカウントがFreeプランの場合は、移譲先アカウントのプランがFreeまたは有料であるかによらず失われる情報がないため、下記画面のように警告は記載されないダイアログとなります。 スクリーンショット 2020-06-11 23.37.41.png

移譲先のOrganizationにTeamが作成されている場合は、移譲後にRead権限を自動で付与するTeamを任意で指定可能です。[Transfer]をクリックして移譲を開始します。 image.png

Moving repository to <移譲先Org名>/<Repository名>. This may take a few minutes.と表示が出るので移譲が完了するまで待ちます。 7a20ebf8-7004-447b-9411-1712e1f0614a.png

移譲元OrgからRepositoryが削除され、移譲先OrgでRepositoryにアクセス可能となれば移譲は完了です。 スクリーンショット 2020-06-11 23.41.00.png

仕込んだ情報が引き継がれているかの確認

移譲先のOrganizationで移譲前にRepositoryに対して仕込んだ情報が移譲後にも引き継がれているかを確認してみます。

  • commit、branch、Pull request

引き継がれました。移譲後にPull RequestのMergeも実施できました。 79aad6c9-69ce-47c1-b600-cd6e739dc50b.png

  • package

引き継がれました。 スクリーンショット 2020-06-11 22.13.45.png スクリーンショット 2020-06-11 22.13.45.png

  • release

引き継がれました。 スクリーンショット 2020-06-11 22.17.05.png

  • Issue

引き継がれました。 1be372a1-c80c-46db-9870-882080390d81.png

  • Project

引き継がれました。ボード上のリスト、カード、Issue、Assigneesもちゃんと引き継がれていました。 スクリーンショット 2020-06-11 22.21.40.png

  • Secret

引き継がれました。 スクリーンショット 2020-06-11 22.42.51.png

  • Actionの実行履歴

引き継がれました。引き継ぎ後に実行されたCIも元の実行履歴に対する新しい履歴として追加されました。 スクリーンショット 2020-06-11 22.27.53.png

  • アクセス権限
    • ユーザーに直接付与されたアクセス権限:引き継がれました。 スクリーンショット 2020-06-11 21.51.34.png
    • Teamを介して付与されたアクセス権限:引き継がれませんでした。(これは想定通りでした) スクリーンショット 2020-06-11 21.38.45.png
  • Circleのプロジェクト、CI実行履歴

プロジェクトは、移譲元のOrganizationの一覧からは消えており、 59eba1dd-ef24-438b-aa86-21f16b37e4c4.png

移譲先のOrganizationの一覧に自動で追加されていました。 スクリーンショット 2020-06-11 23.07.06.png

移譲前のCI実行履歴は移譲後のRepositoryのプロジェクトに再紐付けされていました。また、移譲後にGitHub側で実行されたCIも元の実行履歴に対する新しい履歴として追加されました。 74654e97-5316-4316-a320-14d1e140f0d6.png

  • TravisCIのCI実行履歴

移譲元のOrganizationのRepository一覧からは消えていました。 スクリーンショット 2020-06-11 22.48.00.png

移譲先のOrganizationのRepository一覧には追加されていました。 スクリーンショット 2020-06-11 22.50.16.png

移譲前のCI実行履歴は移譲後のRepositoryのものに再紐付けされていました。また、移譲後にGitHub側で実行されたCIも元の実行履歴に対する新しい履歴として追加されました。 3bb831b2-ad43-43fe-acf8-b3e05b35c22b.png

  • BitriseのApp、CI実行履歴

移譲されたRepositoryに紐づくAppとCI実行履歴は移譲後も同じBitrise Organizationに残ったままとなりました。移譲後にGitHub側で実行されたCIも元の実行履歴に対する新しい履歴として追加されました。 image.png

移譲後のURLリダイレクトの動作を確認してみる

Repositoryを移譲した後も仕様としてはRepositoryの旧URLへのアクセスは新URLへリダイレクトされる動作となりますが、GitHubとしてはURLを更新することを強く勧めているようです。

All links to the previous repository location are automatically redirected to the new location. When you use git clone, git fetch, or git push on a transferred repository, these commands will redirect to the new repository location or URL. However, to avoid confusion, we strongly recommend updating any existing local clones to point to the new repository URL.

ここでは、ドキュメントどおりに移譲後のURLリダイレクトがちゃんと動作するのかを確認してみます。

CLIでのpull、push操作

ローカルRepositoryのGitHubに対するリモートURLは移譲元Organizationのもののままの状態です。

$ git remote -v
origin  https://github.com/<移譲元Organization>/test-python-prj.git (fetch)
origin  https://github.com/<移譲元Organization>/test-python-prj.git (push)

pull操作を実施できました。

$ git pull origin master
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
From https://github.com/<移譲元Organization>/test-python-prj
 * branch            master     -> FETCH_HEAD
   9622c84..59eb0e5  master     -> origin/master
Updating 9622c84..59eb0e5
Fast-forward

push操作を実施できました。

$ git push origin fix-config
Counting objects: 3, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 294 bytes | 294.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: This repository moved. Please use the new location:
remote:   https://github.com/<移譲先Organization>/test-python-prj.git
remote: 
remote: Create a pull request for 'fix-config' on GitHub by visiting:
remote:      https://github.com/<移譲先Organization>/test-python-prj/pull/new/fix-config
remote: 
To https://github.com/<移譲元Organization>/test-python-prj.git
 * [new branch]      fix-config -> fix-config

Webアクセス

https://github.com/<移譲元Organization>/test-python-prjにブラウザからWebアクセスすると、https://github.com/<移譲先Organization>/test-python-prjにリダイレクトされる動作となりました。

旧URLから新URLへのリダイレクトは移譲実施後にちゃんと動作するようです。

結論

GitHub Organization間でRepositoryを移譲(Transfer)すると、移譲前のRepository上のほぼすべての情報が問題なく移譲後も引き継がれることが検証により確認できました。

CIサービス側の紐付けも自動で切り替わるのは意外でした。CIサービス側での移譲後のRepositoryの再紐付けが移譲作業時の一番の手間だと考えていたため、これはとても助かりますね。

結論としてはRepository移譲機能は情報をOrganization間でよしなに移譲してくれるとても優秀な機能だということが分かりました。

以上