GitのバックログからGitHubへの移行を振り返って

年末といえば振り返りということで、今年……ではなく正確には昨年に実施したのですが、GitをバックログからGitHubへ移行した作業について振り返ってみます。
実際に移行したのは今年ではなく昨年の秋ごろでしたが、移行してからちょうど1年が経ったので、改めて振り返ってみようと思います。

TL;DR

全体的には成功！と言っていいはず
Pros:
- プルリクのレビュー改善（特にGitHub Copilot）
- GitHub ActionsによるCI/CDの導入
- 外部サービス（主にAWSやGCP）との連携性の向上
Cons:
- ユーザー人数分の月額コスト
- GitHubのUIなどに慣れるまでの時間

GitHub移行の背景

GitHubへ移行する前、弊社ではバックログに付属しているGit機能を使っていました。バックログを開発しているNulabはサル先生のGit入門を公開していますし、バックログにも基本的なGit機能は充実していました。

しかし、AWS CodePipelineでビルド・デプロイする場合はCodeCommitにリポジトリがあるなど、プロジェクトによってリポジトリの場所が異なることがありました。また、バックログには最小限の機能は揃っているものの、GitHubに比べるとプルリクエストやCI/CDの機能が限定的だったため、より良い開発フローを目指すには物足りない部分もありました。

これは私見ですが、プルリクエストの機能はGitにおいて特に重要だと考えています。バックログのプルリクエストはよく言えばシンプルで分かりやすかったのですが、コード品質を向上するためのレビューが難しいと感じることが多かったです。具体的な点としては、バックログは…

プルリクの担当者 (GitHubで言うAssignee) と承認者 (GitHubで言うReviewer) が区別できない
プルリクの承認機能がない
プルリクをマージする条件を指定できない (レビュー必須や、CI必須)
コードに関する議論がしづらい
ソースコードに行単位でコメントを付ける機能が実はバックログにもあるのですが、弊社ではほとんど使われていませんでした

そういった背景があり、2024年の開発部アクションプラン（社内の業務改善プロジェクト）としてGitHub導入を提案し、2024年10月から12月ごろにGitHubへの移行を実施しました。
なお、GitHubにもプロジェクト管理(Project)や課題管理(Issue)の機能がありますが、プロジェクト運用を全体的に変えたくなかったのでバックログの運用も継続しています。

GitHubへの移行手順

最初にバックログにあるリポジトリをリストアップして、既存リポジトリの名前、バックログのプロジェクト名、開発担当者の名前などをまとめました。バックログのAPIで全リポジトリを取得して、担当者名を割り当てる使い捨てのスクリプトをかいた記憶があります。そのスプレッドシートにさらに、移行後のリポジトリ名やそもそも移行の要否、作業状態（未作業、移行中、完了）などの列を追加して進捗を管理するようにしました。

移行後のリポジトリ名は少々悩んだところですが、バックログのプロジェクトキーと既存リポジトリ名をアンダーバーでつないだ形にしました。例えば、バックログのプロジェクトキーがPROJで、リポジトリ名がmy-repoであれば、GitHubのリポジトリ名はPROJ_my-repoとなります。バックログでの課題管理は継続しますし、リポジトリの移行前後で分かりやすくするためにこのようにしました。

またもう1つ検討したのはリポジトリの移行方法です。リポジトリ数が多かったので、当初はスプレッドシートの内容を元にGitHub CLIでまとめてリポジトリ作成・移行までやってしまおうかと考えていました。しかし、各プロジェクトでキリのよいタイミングで移行したかったことや、私が1人で実施するより各担当者にやってもらった方が良さそうかなと考え、手順書を渡して開発部全員に実施いただくことにしました。ちょうどその時期は私が別のプロジェクトで忙しかったという事情もあるのですが、結果的には各担当者がオーナーシップを持って移行できたように見えるので良い方法だったと思います。

ちなみに、共有した移行の手順書はこのような感じでした。最も重要なのは https://github.com/new/import?owner=e2info&visibility=private というページからリポジトリを作ってもらうことです。GitHubの画面右上にある「＋」メニューからリポジトリを作ると、個人所有のPublicリポジトリがデフォルトになってしまいます。URLのクエリパラメータで初期値を指定できる (GitHub Doc) ので、このURLから作成するようアナウンスしました。

## 0. バックログ側の準備（初回のみ）

バックログの「個人設定」の「パスワード」を開いて、Gitの新しいパスワードを発行します（参考：[特別なパスワード](https://support-ja.backlog.com/hc/ja/articles/360035641734-%E7%89%B9%E5%88%A5%E3%81%AA%E3%83%91%E3%82%B9%E3%83%AF%E3%83%BC%E3%83%89)）

発行したパスワードは同じ画面から確認できます。GitHub移行が終わって使わなくなったら、削除してください。

## 1. GitHubでリポジトリを作成（インポート）する

https://github.com/new/import?owner=e2info&visibility=private

上のURLを開いて、該当項目を入力します。

- The URL for your source repository
    - 移行対象のリポジトリのURL (HTTPS)を入力します
    - 例) https://example.backlog.jp/git/PROJ/repository-name.git
- Your username for your source repository
    - バックログに登録している自分のメールアドレス
    - 例) example@e2info.com
- Your access token or password for your source repository
    - バックログの設定画面から作成したパスワード
    - ※ バックログのログインに使っているパスワードはGitHubに入力せず、設定画面から作成したGitHub移行のためのパスワードを使うようお願いします
    - 例) xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
- Owner
    - **Ownerが "e2info"**  になっていることを確認
- Repository name
    - 新規リポジトリ名を入力
    - 例) PROJ_repository-name
- リポジトリの公開設定
    -  **公開設定が "Private"** （鍵のアイコン）になっていることを確認

問題なければ、最下部にある "Begin import” ボタンを押します。

"Preparing your new repository" の画面が出てきて、数分ほどかかります。
チェックマークが出てきたら完了です。
作成したリポジトリのページを開き、リポジトリ内容を確認してから次の手順に進みます

## 2. GitHubのリポジトリ設定

リポジトリの設定画面を開いて、各種設定を行います

### ◆ デフォルトブランチを確認する

リポジトリの設定画面の General で、まずデフォルトブランチを適切なブランチ（masterやdevelopment）に変更します。
※ プルリクを作成するときのマージ先や、リポジトリをGitHubで表示したときのデフォルトとなります

### ◆ リポジトリの不要な機能オフ

現状では、GitHubのWikiやProjectの機能は使わない予定なので無効化します。

Featuresの項目で、

- Wikis のチェックを外す
- Issues のチェックを外す
- Projects のチェックを外す
- Allow forking のチェックを外す

の操作をします。確定ボタンはありません

### ◆ リポジトリの権限設定

デフォルトだと書き込み権限が誰にもないため、アクセス権限を設定します。リポジトリの設定画面の左側ナビゲーションバーから "Collaborators and teams" を開き、緑色の "Add teams" をクリックします。

- `e2info/e2info_developer` に Write権限

各プロジェクトごと、必要に応じてパートナーさんや他のチームにもWrite権限を設定します。

※ チームを使わず "Add people" で個人ごとに権限設定もできますが、GitHubの全ユーザーが検索対象になってしまいます。操作ミスで全然関係ないユーザーを招待してしまいうるので、個人ごとの招待は原則使用せず、パートナーさん１名ごとに個別のチームを作成する運用にします。

### ■ リポジトリ一覧シートを更新

- 対象リポジトリの **進捗** を「2. プッシュ済」に更新してください

## 3. 移行後対応

### ◆ バックログリポジトリにプッシュを禁止

GitHubとバックログで別々なコミットをしてしまうと困るので、バックログ側にプッシュできないようにします。

バックログのリポジトリ設定を開きます

ブランチ保護ルールの「ルール追加」ボタンを押して、保護パターンに `*` を設定します。

### ◆ デプロイの対応

phployの場合は、デプロイサーバーのGitリポジトリの設定をGitHubに変更します。
方法は、ローカルの開発環境と同じです。ただし、SSHではなくHTTPSのURLを設定することに注意してください。

```
cd /home/e2info/path/to/project
git remote set-url origin https://github.com/e2info/PROJ_repository-name.git
```

CodePipelineを使っている場合は、AWSのマネジメントコンソールでCodePipelineの設定を変更してGitHubからコードを取得するようにします。

### ◆ 周知作業

略

### ■ リポジトリ一覧シートを更新

- 上記の移行作業が途中の場合、対象リポジトリの **進捗** を「3. 移行中」に更新してください
- 必要な作業が終わった場合は、対象リポジトリの **進捗** を「4. 完了」に更新してください

移行作業はスムーズに進み、大きな問題はありませんでした。何個かエラーで移行できなかったリポジトリもあったのですが、主に「DBのダンプファイルなど、100MBを超えるファイルが含まれている」という理由でした。バックログでは問題なかったのですが、GitHubで大きいファイルはGit LFSを使う必要があります。巨大なファイルもGit管理する従来運用が望ましくなかったので、各担当者に大きいファイルをGitの管理外にするなど対応 (GitHub Doc)いただきました。

また、移行直後は慣れないことによる戸惑いもあったようです。私のようなタイプはむしろGitHubの方が使い慣れていますが、特にエンジニアでないメンバーは英語のUIに抵抗があるなどの意見もありました。その点は、GitHub導入に賛成＆承認してくれた金子さん(CTO)が、社内向け講習会を実施するなどサポートくださりました。他の開発メンバーも不慣れなメンバーをフォローしてくれるなど、遅ればせながらありがとうございました！

移行の効果① レビュー体制の改善

2024年12月にはほとんどのリポジトリの移行が完了し、GitHubでのリポジトリ管理が始まってちょうど1年が経ちました。日常の開発業務でいろいろ良かったことや、改善点が見えてきたのでまとめてみます。

まず一番大きい変化はプルリクエストのレビュー体制が改善したことかと思います。正直に言えば、バックログだったときプルリクエストを詳しくコードレビューする文化がありませんでした。GitHubではコードが見やすく、コードについて「これ問題ない？」「この仕様はクライアントOKもらってます」「LGTMです」みたいなコメントを付けやすいです。

GitHub Copilotによるプルリクエストのレビューも大きな要因です。移行計画時点ではまだGitHub Copilotのレビュー機能はなかったのですが、移行後に導入したことでコードレビューの質が大きく向上しました。コードレビューがあまり活発でなかったのはレビュワーの時間確保の問題も大きく、そこでGitHub Copilotがレビューしてくれることでコード品質の向上に大きく役立っていると実感しています。

また、コードレビューのプロセス・フローの変更も良い効果がありました。バックログでは「担当者がプルリクを作成→レビュワーが承認＆マージ」という承認した人がマージまで実施する流れでした。GitHubでは「担当者がプルリクを作成→レビュワーによる承認→担当者が自分でマージ」という流れを自然に取り入れられます。レビュワーが開発の主担当で他の人に作業依頼した場合は前者でも良かったのですが、作業者自身が開発の主担当だったとき、レビュワーがプロジェクトに詳しくない（セカンドチェック的な立ち位置の）場合があります。その場合は主担当が、自分の権限で、自分のタイミングでマージできるGitHubの方が便利です。