1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Qiita記事と画像をGitで管理

1
Last updated at Posted at 2026-07-14

概要

Qiitaの記事をGitリポジトリで管理する試みは昔やろうとしましたが、結局、二重管理が手間でやめてしまいました。最近コーディングエージェントを使うようになって、Qiita記事をgit管理・編集できる利便性が、二重管理の手間を上回ってきた気がするので、改めてやり方を考えました。

git管理にあたってはQiitaのAPIが画像アップロードに対応していないために1つのリポジトリで記事と画像を両方管理するという運用がはまらないことがネックでした。
そこで多少の妥協案ではありますが、画像公開用のパブリックリポジトリと記事管理用のプライベートリポジトリを併用することで、対応しました。

方法: 画像は公開リポジトリ + jsDelivr

Qiita APIには画像アップロード機能がないため、画像を記事と共通のリポジトリで管理して、API経由でアップロードし、記事のURLを差し替える、みたいな運用がハマりません。
そこで、発想を変えて、画像をQiitaに置くのをやめ、自分の公開GitHubリポジトリに置いてCDN経由で参照することにしました。

  • 画像専用の公開リポジトリを1つ作る(例: user/qiita-images
  • 記事本文では https://cdn.jsdelivr.net/gh/user/qiita-images@main/path/to/foo.jpg を参照する
  • jsDelivrはGitHubの公開リポジトリを無料でCDN配信してくれる

この方法のメリットは主に以下です。

  1. 記事リポジトリはプライベートのまま(下書きを晒さずに済む)。公開されるのは画像だけ
  2. 画像を差し替えて push すると、同じURLのまま中身が更新される=記事側の画像も更新される。したがって画像もバージョン管理できる。
  3. 画像パスを公開URLにできるので、ローカル、GitHub、Qiitaで常に同じ場所を参照できる(相対パスでの指定だと、ローカルとGitHubで位置がズレたりする)

逆にデメリットは以下です。これは今回許容としました。

  1. 画像は下書き時点で公開される
  2. リポジトリが2つになり管理が煩雑

おわりに

QIITA_TOKENとGITHUB_ACTIONSを組み合わせた自動公開の方法などは生成AIがよしなに設定してくれるので、省略します。
上記の考え方だけ、採用不採用を人が判断する必要があるためメモとして残しました。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?