GitHub ReleaseとTagの基本
Tagは特定時点の印、Releaseは配布や公開バージョンとして見せる情報です。公開する前に、説明文と添付ファイルの中身を確認します。
このページでわかること
- tagは履歴上の目印
- releaseは公開バージョンとして使う
- release notesと添付ファイルを確認する
まず確認すること
- 何を変えたかを書く
- 重要な変更や互換性の注意を分ける
- Secretsや内部情報をnotesや添付物に入れない
やってはいけないこと
- 添付ファイルの中身を見ずに公開する
- 配布後の安全を保証する表現にする
- 内部ログをそのまま転記する
安全寄りに進める手順
- 対象のrepo、branch、PR、Actions runを確認する。
- Secrets、APIキー、token、.env、個人情報が差分やログに出ていないか見る。
- 必要な場合は値を停止または再発行し、影響範囲を整理する。
- 変更は小さなbranchとPRに分け、CIとreviewで確認する。
CodexやAI作業時の注意
AIに作業を渡す時は、対象ファイル、触らないファイル、確認項目を明記します。認証情報や実際のキー値は本文、Issue、PR説明、ログ、レポートに残さないようにします。
公式情報で確認する領域
Actions、Secrets、PR、repository visibility、workflow permissionsは仕様が変わることがあります。実作業前にはGitHub Docsで最新の説明を確認してください。
TagとReleaseは「この時点が区切り」の目印
commitが日々の記録だとすると、Tagは「v1.0」のような節目の目印、ReleaseはそのTagに説明文や配布ファイルを添えた公式な区切りです。サイト運営で例えるなら、commitは毎日の更新記録、Releaseは「リニューアル完了」のような節目の宣言にあたります。目印を打っておく最大の実益は、「あの安定していた時点に戻りたい」となった時、無数のcommitの中から探さずに一発でその地点へ戻れることです。
個人サイト運営でも役立つ使い方
- 大きな変更の前にTagを打つ — サイト全体のデザイン変更やAIへの大玉依頼の前に「v-before-redesign」のようなTagを打っておくと、最悪の場合の戻り先が確保できる
- 安定版の宣言として使う — 「この状態は全ページ表示確認済み」という時点をReleaseにしておくと、以降の変更で問題が出た時の比較基準になる
- AI作業の節目に使う — CodexやClaude Codeに連続で作業させる期間の開始前にTagを打つと、「AI作業前」と「AI作業後」の差分を後からまとめて確認できる
Tag名は「v1.0」形式にこだわる必要はなく、「何の時点か」が分かる名前で構いません。打ちすぎて困ることはほぼないので、「戻りたくなるかもしれない時点」で気軽に打つ習慣がおすすめです。