Posted by こんにちは。
運用プロジェクトでバックエンドのアプリケーションエンジニアを担当している森と申します。
この記事ではうちのプロジェクトでGitのリポジトリマネージャーをGitLabからGitHubに移行した際の流れや教訓について書きます。
今回の記事はアプリケーションエンジニア視点からのものですので、インフラ視点からの移行については後日紹介される記事をご覧ください。
なぜ移行しようと思ったのか
GitLabのバージョン7.6.2を使っていたのですが、いくつか不満がありました。
主なものは以下の3点です。
1. squashマージをブラウザ上からしたい
うちのプロジェクトでは開発ブランチをmasterブランチにマージする際にsquashマージしてコミットを1つにまとめるルールがあり、開発ブランチのレビューが終わった後にそのままマージリクエストからsquashマージをしたいという要望がありました。
2. ブランチが更新されたらマージリクエストも自動で更新したい
ブランチをリモートにpushしてもマージリクエストが自動で最新の内容にならず、いったんマージリクエストをcloseしてreopenしないと反映されませんでした。
そのため、最新の内容が反映されていない古い状態のマージリクエストをレビューしてしまうなどの問題が発生していました。
3. 新たにリモートにpushしたブランチがすぐにGitLabのブランチ一覧に反映されないことがあった
新たにpushしたブランチがすぐにGitLabに反映されず、最長10分くらい待たないと反映されないということが結構起こりました。
緊急リリースの際にマージリクエストがすぐに作れないため、これになかなか悩まされました。
インフラチームに相談し、GitHubへの移行が決定しました。
また、移行の際に画像などのバイナリファイルをGit LFSを使って管理することになりました。
レポジトリの再構築
GitHubに画像などの容量の大きいバイナリファイルをそのままあげないため、それらはGit LFSで管理する必要があります。
そのため、単純に現在のレポジトリを移行するだけでは不十分で、Git LFSに対応させるためにレポジトリのコミットを1から構築し直す必要があります。詳細はインフラ編で。
移行準備
1. メンバー全員にGitHubアカウントを準備してもらう
持ってない人には会社のメールアドレスで新たにアカウントを作ってもらい、既に持っている人は既存のアカウントを使うか新たに作成するかを選んでもらいました。
また、GitHubと通信するためのSSHの設定もしてもらいます。
2. GitHub移行後のローカル環境更新手順のドキュメント作成
Git LFSを利用することになったため、今まで使用していたリポジトリをそのまま使うことができず、全員新たにリモートから1からcloneする必要がありました。
また、うちのプロジェクトは多くの人がGitクライアントにSourceTreeを使っていましたが、古いバージョンだとLFSに対応していなかったため、全員最新のバージョンにアップデートしてもらいます。
3. GitHub移行後のマージフローの作成 & ドキュメント化
GitLab、GitHubでUIが変わっていたり、squashマージができるようになったことでマージフローが少し変わったので、その辺りをドキュメント化しました。
（他にもGitHubでは権限やマージするための条件をきめ細かく設定できますが、試した結果プロジェクトにあまり合わなかったのでこちらは設定しませんでした。）
4. 移行するブランチの調査
Git LFS対応で移行日を境にレポジトリが変わるため、移行日をまたがって使用する開発ブランチは移行対応をする必要がありました。
なので、「移行ブランチ一覧」のページを社内wikiに作り、そこに各自移行日移行も使いたいブランチを書いてもらいました。
5. GitHub移行日の設定
移行する日はGitHubからのcloneや、SourceTreeのアップデートに時間がかかることが想定されたため、リリースがほとんどなく、緊急対応が発生しなさそうな日を選んでそこに設定しました。
移行当日
1. リポジトリ変換
インフラチームにGit LFSに対応するようリポジトリに変換をかけてもらいましたが、叩いたコマンドが進まなかったりとトラブルが発生しました。
こちらの詳細は後日公開予定のインフラ編をご覧ください。
2. ローカル環境更新テスト
普段Macを使っている自分と、Windowsを使っているもう一人の人が早めに出社して更新手順のドキュメントに従ってローカル環境を更新。
だいたい40分〜1時間でローカル環境を新レポジトリに更新できました。
3. ローカル環境更新
プロジェクトの全員に手順に従って移行手順を実施してもらいました。上記の更新テストで特に問題が起こらなかったので大丈夫かと思っていたのですが、3〜4時間経ってもローカル環境の更新が完了しない人が続出。
原因はおそらくGit LFSの実体のダウンロードが妙に時間がかかっていること。社内ネットワークなのかGitHub側なのかはわかりませんが、プロジェクトの人が同時にcloneしていたため、ネットワーク帯域が足りなかったのが原因だったようです。
仕方ないので、急ぎの人以外は中止してもらって、別の日に移行してもらうことで対応しました。
移行してよかったこと
移行動機であった3点の問題が全て解消された
問題であった場所は全て解消されました。
動作が早い
巨大なプルリクエストの表示がGitLabよりだいぶ早いです。
ブラウザからコミット/コンフリクトの解消/ブランチ作成ができる
ブラウザからある程度Gitの操作ができるので、簡単な操作ならリポジトリが使えない状況でも更新することができます。
不要なブランチを見直すきっかけになった
必要なブランチ以外は全て消すことができました。
移行して悪かったこと
WindowsのSourceTreeの動作が極端に重くなった
Git LFS対応のために全員SourceTreeを最新版にしてもらいましたが、WindowsのSourceTreeが重く、業務に支障をきたすレベルでした。
SourceTreeの設定でシステムのGitを使うようにすることである程度解消されましたが、いまだに解消されていない人もいます。
参考: Windows版SourceTree2.xが遅い時の確認 – よしたかの日常
移行改良手順
全員で一斉にGitHubのリポジトリをcloneするととても重いので、あらかじめ一人がcloneをしておいて、それをzipで固めてプロジェクトメンバーに配布する、というやり方が有効でした。おすすめです。
まとめ
さて、GitLabからGitHubへの移行についてアプリケーションエンジニアの視点からお話しましたがいかがだったでしょうか。
ぜひ後日公開予定のインフラ視点の記事も合わせてご覧ください！
