複数のプロジェクトをひとつのリポジトリにまとめ、その3週間後に元の構成へ戻しました。やってみて、要らなかったという結論です。往復して分かったことと、移動のときに引っかかった点を残しておきます。
01 — 経緯
まとめて、ほどいた
最初はプロジェクトごとにリポジトリが分かれていました。それをひとつにまとめ、 各プロジェクトをサブディレクトリに置く構成へ変えました。横断的な設定を1箇所で持てるのが理由です。
3週間後、元の「リポジトリのルートがプロジェクト本体」という構成へ戻しました。 167ファイルすべてが移動として記録され、履歴は書き換えていません。 戻した理由は単純で、ひとりで開発している限り、まとめる利点がほとんど無かったからです。 複数プロジェクトを同時に触ることは実際にはなく、パスが一段深くなる不便さのほうが毎日効いてきました。
02 — 引っかかった点
履歴と、設定に残るパス
| 履歴が追えなくなる | 移動をまたいで履歴を見るには git log --follow が要ります。付けないと移動前のコミットが出てきません。 |
|---|---|
| CIの設定 | ワークフローのパスにプレフィックスが入っていると、構成を戻した瞬間に壊れます。移動と同じコミットで直すのが安全です。 |
| .gitignore | 同じくパスを含む行の書き換えが必要です。無視されるはずのファイルが追跡され始めます。 |
| エディタの起動設定 | ローカルの起動設定にも相対パスが埋まっています。CIが通っても気づけないので、実際に起動して確かめました。 |
| 作業メモ | 期間中に書いたメモに古いパスが残ります。日付で読み替える必要が出てきました。 |
03 — 学んだこと
構成の変更は、それ自体が仕事を生む
ファイルを移すこと自体は一瞬で終わります。時間を取られるのは、 パスを覚えている場所を全部見つけて直すことのほうです。 CI、無視設定、起動設定、ドキュメント、そして自分の記憶。 構成を変えるときは、この洗い出しにかかる時間まで含めて判断したほうがいいと思いました。
個人開発では、構成を整えること自体が目的化しやすいところがあります。 往復してみて言えるのは、困っていないなら変えないほうがいい、という当たり前のことでした。
Follow
こういう記録を置いています
個人開発でつまずいた話や、作りかけのものは Instagram（@kenpiro1012）と note にも置いています。 記事の一覧は記事ページにまとまっています。