地味な作業ですが、順番を間違えると取り返しがつかない部分があり、そこが今回いちばんの学びでした。
まず結論
- 思考の記録はGitHubのリポジトリ1つに集約する。形式は「トピック別フォルダ＋日付つきのメモファイル」
- 公開したくないものは、隠すのではなく”別の場所に置く”
- そしてファイルを消す順番は、種類によって逆になる——ここが今回の核心でした
なぜ、メモをGitで管理するのか
初学者向けに、理由を3つに絞ります。
① 書くと、考えが整理される
頭の中のモヤモヤは、文章にして初めて「自分が何を分かっていて、何が分かっていないか」がはっきりします。これは、このブログを書いていて日々実感していることでもあります。
② 記録が、そのまま資産になる
一度ハマったエラーや調べたことを書き残せば、次に同じ場面で過去の自分が助けてくれます。初学者ほど「同じことを何度も調べ直す」時間が多いので、始めるのが早いほど得をします。
③ 低リスクな練習台になる
これは意外な利点でした。Gitの操作やMarkdownの書き方を、「壊れても困らない題材」で練習できるのです。コードと違って動かなくなる心配がないので、入門の教材として最適でした。
形式：完璧を目指さないのが続く秘訣
調べてみると、この手の記録には定番の型がありました。海外のエンジニアが実践している「今日学んだこと」を淡々と積む方式です。構成はシンプルで、こんな形。
my-brain/ ├── python/ │ └── 2026-08-20-仮想環境とは.md ├── git/ │ └── 2026-08-21-コンフリクト解消.md ├── error-log/ ← ハマったエラー専用 └── ideas/ ← 作りたいものの種
この方式の一番の美点は、「完璧な記事じゃなくていい」という気軽さです。実践者の記録を見ると、長文の日もあれば、リンク2つと一文だけの日もある。初学者が一番つまずく「ちゃんと書かなきゃ」というプレッシャーを、最初から外してくれる形でした。
特におすすめしたいのが、エラー専用のフォルダを最初から分けておくことです。初学者が最も時間を溶かすのはエラー対応なので、ここに専用の引き出しを作っておくと、効果が一番早く出ます。
いちばんの学び：削除の順番が、種類によって逆になる
ここからが本題です。過去のメモには、人に見せたくないものと、単に重複しているだけのものが混ざっていました。どちらも「消したいファイル」ですが——消すタイミングが真逆でした。
機微な情報は「記録に入れる前」に消す
Gitには「一度記録したものは履歴に永久に残る」という性質があります。だから個人的な内容や、外に出せない情報は、最初の記録より前に消しておく必要があります。後から消しても履歴の中には残り続けるからです。
単なる重複は「記録に入れた後」に消す
逆に、ただの重複ファイルや古い版は、一度記録してから消すのが正解でした。理由は同じ性質の裏返しで、履歴に残るから「消して後悔」がゼロになるのです。
これは私自身、危うく失敗するところでした。整理案では「先に全部消してから記録する」となっていたのですが、それだと古い版にしか書かれていなかった内容が、完全に消滅していました。
Gitの「消えない」性質は、守りたいものには脅威になり、
失いたくないものには保険になる。
同じ性質なのに、扱う対象で意味が反転する。
この非対称性に気づけたのが、今回いちばんの収穫でした。
もう一つの原則：隠すのではなく、置き場所を分ける
「公開したくないファイルをどう守るか」についても、方針を決めました。設定で除外するのではなく、そもそも公開する場所の外に置く、という形です。
なぜか。除外設定は「うっかりを防ぐ盾」であって、書き忘れや書き間違いが1回でもあれば公開されます。初学者が最初にやる事故の代表格が、まさにこれ（設定ファイルや鍵の流出）です。
盾を信じるより、そもそも戦場に持ち込まない。ファイルが増える前——つまり今——に置き場所のルールを決めておくのが、一番安上がりでした。
コピーの作法：非破壊で、原本はすぐ消さない
実際の引っ越しでも、2つ気をつけました。
- コピーは、途中で止めても再開できる方法で行う。何をコピーしたかが全部記録に出る方法を選びました。初学者ほど「何が起きたか見える」道具を使うべきだと思います
- 元のフォルダは、しばらく消さない。コピー漏れは、探し物をしたときに初めて気づくからです
これも、このブログでずっと書いてきた「戻せる状態を作ってから進める」の実践でした。
おまけ：課題管理は「意思決定のログ」だった
あわせて、GitHubの課題管理機能（Issues）も使い始めました。ここでも認識が変わったことが一つ。
Issuesは「やることリスト」だと思っていたのですが、実際に効くのは記憶の代わりとしてでした。個人開発は中断と再開の繰り返しで、1週間ぶりに開いたときに過去の自分のメモを読めば30秒で文脈を思い出せる。これは他の道具では得にくい価値です。
そしてもう一つ。Issuesは「なぜそれをやると決めたか」の記録であり、その決定がコードに変わった記録が変更履歴——この線がつながると、3か月後の自分がいちばん助かります。「なぜ」を言葉にして残すという、私が自分に課している原則を、コードの世界でやるのがこれでした。
おわりに ── 知識にも「真実は1箇所」
このブログで何度も書いてきた原則が、「真実は1箇所に」です。同じ内容のファイルが2つあると、いつか古いほうが動き出して事故になる——コードの話として書いてきました。
今回やったのは、それを自分の知識に適用する作業でした。メモアプリに散らばり、複数の場所に似た内容が並んでいた状態を、1か所に集約する。探すときに迷わない、という一点だけで、記録の価値は跳ね上がります。
作業自体は地味で、新しい機能は何も増えていません。でも、書いた記録が確実に残り、必要なときに1か所を見れば済む——この土台があるから、次の学びを安心して積める。記録の置き場所を決めるのは、未来の学習速度への投資だったと思っています。
個人開発 / 学習メモ / GitHub / 知識管理
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
