気付いたら GitHub の repo が6個に分かれていた話
ツール工房.ai を作り始めたころは、GitHub の repo を1つにまとめていれば足りるだろう、と漠然と考えていました。コードはぜんぶそこに置いて、必要なら整理すればいい、くらいの感覚です。
ところが、サイトやツールが増えていくたびに、「これ、別の場所に分けておいたほうが楽じゃないか」と思う瞬間が増えていきました。気付いたら手元には6個の repo があり、それぞれちょっとずつ役割が違っています。最初から設計したというよりも、「分けないとうまく動かない場面」に何度かぶつかって、結果としてこの形に落ち着いた、というのが正直なところです。
ざっくり整理すると、私の repo たちは「サイトやツールのコードを置く場所」「下書きを集めておくための場所」「メッセージだけを流す場所」の3種類に分かれています。
自分でコードを書くための場所
まず、サイトのコードを置いている repo がいくつかあります。メインサイト・子連れスポット・楽天最安値検索（買い物）・お金診断、と用途ごとに分けて4つです。一つのサイトが大きくなってきた段階で、「ここはもう別の repo にしておこう」と切り出した結果です。
これとは別に、ホテル検索のように GitHub を介さず、ローカルから直接公開先に送り出しているツールもあります。すべてを GitHub に乗せる必要はなくて、「自動化を回したいものだけが GitHub に置いてある」という感じになっています。
増やしすぎると管理が大変になるので、新しい repo を作る前には「本当に分ける意味があるか」を一度考えるようにしています。
下書きだけを集めておく場所
次に作ったのが、未公開の下書きだけを集めておく専用の repo です。
きっかけは、下書きを公開サイトのコードと同じ場所に置きたくない、という気持ちでした。最初のうちは公開サイトの repo に下書きをそのまま置いていたのですが、公開ログに未レビューのものが混ざってしまうのが地味に気になっていました。そこで、下書きだけを集めておく専用の repo を別に作って、レビューを通したものを公開サイトの repo に移す、という形に切り替えました。
この repo を独立させたら、「未レビューの下書きが、公開サイトのコードに混ざらない」状態になって、自分の頭の中もすっきりしました。下書きはレビューを経てから公開サイトの repo に正式に移される、という二段階の流れで運用しています。
メッセージだけを流す場所
3つ目は、通知メッセージだけを流すための repo です。これは少し変わった使い方をしていて、最初に作ったときは自分でも「これ repo の使い方として変じゃないか」とちょっと笑っていました。
クラウド側で動く自動化は、外部サービスに直接 HTTP リクエストを送ろうとすると、接続できないことがあります。それを回避するために、通知したい内容を JSON にして専用 repo に push し、別の仕組みがその repo を監視して通知を実際に届けてくれる、という流れにしました。
いまは、はらぺこあおむし関連のイベント通知でこのパターンが動いています。今後ほかの通知にも転用できそうだなと思っていますが、まだ実際に増やしてはいません。「変な使い方だなと思いつつ、結果として動いているからよしとしている」というのが今の心境です。
うっかり削除して、半日止めた話
repo が増えてくると、当然「どれが使われているのか分からない」気持ちが芽生えてきます。
ある日、「もう使っていないかも」と思った repo を、依存関係を確認せずに消してしまいました。すると、その日の自動化がエラーで止まりました。慌てて再作成し、必要なファイルを push し直して復旧しましたが、結構ヒヤッとした出来事でした。
以来、「repo を消す前に、どの自動化から参照されているかを確認する」を自分のなかのルールにしています。どの自動化がどの repo を見ているかは、別途まとめノートに表形式で残してあって、消す前にそこを必ず眺めるようにしました。
分け方の自分なりの基準
repo を分けすぎても煩雑になるので、分けるかどうかの判断は次のような視点でしています。
- 内容のタイプが違う（コードと、原稿の下書き）
- 公開度が違う（下書き段階と、公開サイトに乗るもの）
- 責任範囲が違う（コード本体と、通知メッセージのような「データだけ」のもの）
逆に、用途が似ているならわざわざ分けず、フォルダ分けで済ませることが多いです。「迷ったら、まずは分けないでおく」を初手のルールにしています。
ぜんぶ Private にしている理由
ちなみに、ツール工房.ai の repo はすべて Private にしています。
オープンソースとして公開する選択肢もあるにはあったのですが、
- 試行錯誤の途中で書いた、内部情報を含むコミットが履歴に残っている
- アフィリエイトの識別子や、運用メモが過去のコミットに紛れている可能性がある
- 端末名やフォルダ名が古いコミットに残っていることがある
といった「過去の自分が残した痕跡」が気になって、Private のほうが安心できると判断しました。後から「ここだけ公開したい」と思ったときは、その部分を別の Public repo として切り出せばいいので、最初から全部公開する必要はないかなと考えています。
機密情報（API キーやパスワード類）については、repo の中には基本的に置かないようにしています。Cloudflare Pages の Secrets や、必要に応じて GitHub Actions の Secrets に入れて、コードの履歴には残らない場所で管理しています。一度コミットしてしまうと、削除しても履歴から消すのが大変なので、「最初から入れない」を徹底するのが安心です。
派手じゃないけれど、地味に効く
最初は1つで足りるはずだった repo が、気付いたら6個に分かれていた、というのが正直な感想です。設計してこうなったというより、自動化を増やすたびに「これ、分けないと辛いな」とその場で気付いて、少しずつ整っていった結果です。
派手な工夫ではないですが、いろいろ作っていくとそれぞれが混ざってしまいやすいので、こういう地味な分離が後々効いてくるなと感じています。一気に整理しようとせず、必要になったときに少しずつ分ける、くらいのペースが個人開発には合っているのかもしれません。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ