MDX ブログの Git 運用：記事ブランチとリリースのリズム

コードと記事が同じリポジトリにあると、コミットの粒度で迷います。「記事一本＝コミット一本」に寄せるか、「まとめて週次でマージ」に寄せるかは人それぞれですが、トラブル時に戻しやすい形だけは揃えておきたいです。

ブランチ方針の例

• main: 本番に近い状態。デプロイの既定ブランチ。
• posts/スラッグ短縮: 記事単体や関連修正だけ。プレビュー URL を共有しやすい。
• fix/...: サイト本体のバグ修正。記事と混ぜないと履歴が読みやすい。

個人開発なら 全部 main 直コミットでも回りますが、有料記事の先行公開や誤字修正のレビューを将来入れるなら、早めに posts/* の癖を付けておくと楽です。

コミットメッセージ

プレフィックス例：feat、fix、post、chore。記事追加なら post : タイトル短縮 のようにすると、git log --grep がしやすいです。プロジェクトのルールに合わせてよいですが、検索可能性だけは確保したいです。

下書きと draft フラグ

draft: true は 本番ビルドでは一覧に出ない一方、開発と Preview では見える、という使い分けができます。「まだ公開したくないが、プレビューで読者に見せたい」なら、ブランチを分けて Preview の URL を渡す方が安全なこともあります。公開と同時に draft を外すコミットを独立させると、リバートが簡単です。

画像や添付

リポジトリに直置きするか、外部ストレージに置くかで ビルド時間とリポジトリサイズが変わります。まずは public/ 以下に置き、肥大化してきたら最適化、という段階でもよいでしょう。Git LFS は 個人ブログでは後回しで十分なことが多いです。

まとめ

• 記事とアプリ修正でブランチやコミットを分けられると履歴が読みやすい
• draft と Preview ブランチの組み合わせで先行共有もできる
• メッセージにプレフィックスを付けるとあとで検索しやすい

チーム拡大や CI 厳格化のタイミングで、この記事は捨ててルールブックに置き換えればよいと思っています。