TL;DR
- マルチレポ（5リポジトリ）のプロジェクトをモノレポにしました
-
Git subtreeを使って移行します
モノレポ（Monorepo）とは
ざっくり言うと、複数のシステムを一つのリポジトリで管理する手法です。
モノレポジトリと呼ばれることもあります。
細かいことは詳しいページやGoogle先生で調べてみてください。
マルチレポの頃の構成
hoge1 と hoge2 という2システムから構成されており、それぞれにバックエンド（BE）とフロントエンド（FE）があります。
また、共通のDBを利用します。
- hoge1システム
- hoge1-be
- hoge1-fe
- database
- hoge2システム
- hoge2-be
- hoge2-fe
- database
実際のリポジトリは以下のようになります。
各 X-be から database をサブモジュール化しています。
- hoge1-be
- hoge1-fe
- hoge2-be
- hoge2-fe
- database（Git submodule）
開発時は、database以外のリポジトリをそれぞれdocker compose upしていました。
しんどい点
- 5回
git cloneしないといけない - 一つの機能に対する変更なのにリポジトリをまたいだ変更だとPRが分かれる
- DBがGit submoduleになっているので
git clone --recursiveしないといけない - DBの変更が入ると、hoge1-beとhoge2-beそれぞれでマイグレーションを実行しないといけない
- docker-compose.ymlが各リポジトリにあるので開発時に叩いて回らないといけない
docker関連のGit submodule作れば解決？
モノレポ移行手順
統合先リポジトリを作る
mkdir monorepo
cd monorepo
git init
initコミットを作る（コンフリクトせずにresetしやすい）。
git checkout --orphan main
git commit --allow-empty -m 'init'
統合先リポジトリに各リポジトリを取り込む ×5
取り込むリポジトリ hoge1-be を追加します。
git remote add hoge1-be <hoge1-beのローカルのフォルダ>
またはリモートから取得します。
git remote add hoge1-be git@github.com:account/hoge1-be.git
mainブランチを取り込みます。
コマンド実行後、hoge1-beフォルダが生成され、その配下にhoge1-be/mainが展開されます。
コミットログが受け継がれている状態になります。
git subtree add --prefix=hoge1-be hoge1-be/main
git log --graph
submoduleを使用している場合は以下を実行しておかないとGitHub上でサブモジュールの表示が残り続けることがありました。
git rm hoge1-be/.gitmodules
git rm hoge1-be/<submoduleのフォルダ>
git commit -m 'submodule削除'
リモートリポジトリの設定を削除します。
git remote remove hoge1-be
git push origin main
ここまでの処理を取り込みたいリポジトリ全てに対して行います。
最終的なフォルダ構成
.
├── .git
├── database
├── docker
├── hoge1-be
├── hoge1-fe
├── hoge2-be
└── hoge2-fe
datbaseフォルダはdocker composeのvolumesで hoge1-be と hoge2-be の所定の位置にマウントし共有します。
dockerフォルダは各フォルダに散らばっていたdocker-compose.ymlをまとめています。
docker-compose.ymlのカスタマイズが容易になり、Git管理も楽になりました。
まとめ
以上、簡単ですがマルチレポからモノレポに移行する手順について説明しました。
開発中のマルチレポを移行する場合は、mainをモノレポに取り込んだらマルチレポのmainは触らないでその他のブランチを適宜モノレポに取り込むようにするなどのルール作りがあると良いです。
マルチレポに課題があるようにモノレポにも課題があります。
モノレポでの課題やその対応などは別の記事に書きたいと思います。
参考
- 依存しあう複数の Git リポジトリを git subtree で monorepo 化する