みなさん、こんにちは。
前回の「Gitは思考のログである」というお話、多くの反響をいただきありがとうございました。
ソフトウェア開発において、コードを書くことは「執筆」に似ています。しかし、書いただけで満足していては、それは「下書き」のままです。書いたコードを誰かが使える状態にし、バージョン番号という「タイトル」をつけて世に送り出す。このプロセスが「リリース」です。
GitHub Releasesは、このリリース作業を劇的にスムーズにしてくれるツールです。単にソースコードを公開するだけでなく、リリースノートの自動作成やバイナリファイルの配布、バージョンごとのアーカイブ作成などを一手に引き受けてくれます。
プロフェッショナルな現場、特に私が関わることが多い医療IoTやシステムコンサルティングの現場では、「どのバージョンの時にどの問題を解決したか」を明確にすることが、クライアントや現場のスタッフ（看護師さんや技師さんなど）との信頼関係に直結します。そのための強力な武器が、GitHub Releasesなのです。
GitHub Releases を構成する「三種の神器」
GitHubにおける「リリース」を理解するためには、まず以下の3つの構成要素を押さえておく必要があります。
1. タグ（Tag） – 歴史に打つ「杭」
Gitの履歴（コミットグラフ）の中に、「ここが区切りだ」という目印を打ち込む作業です。ブランチは動いていきますが、タグは一度打つとその場所（コミットハッシュ）に固定されます。いわば、歴史の節目に打つ「杭」のようなものです。
2. リリースノート – 物語の「あらすじ」
前回のリリースから何が変わったのか、どんなバグが修正されたのかを記述するドキュメントです。GitHubの「Generate release notes」機能を使えば、マージされたプルリクエストのタイトルから、自動で美しい「あらすじ」を作ってくれます。
3. 成果物（Assets） – 読者が受け取る「本」
ソースコードそのものではなく、コンパイル済みの実行ファイル（.exeや.apk）や、設定済みのバイナリなどを添付します。エンドユーザーや現場の運用担当者は、ここから直接ツールをダウンロードして使用することになります。
CLIで行う「リリースの土台作り」
リリース作業のスタートは、使い慣れたターミナル（CLI）から始まります。GUIだけでも完結できますが、タグ作成を自分の手で行うことで、ミスを防ぎ、履歴を確実にコントロールできます。
1. コミットの最終確認とPush
まずは、リリース対象となるコードがすべてリモートリポジトリに反映されているかを確認します。
# 作業内容をステージングし、リリース用のメッセージを添えてコミット
git add .
git commit -m "chore: V1.0.0 リリース準備完了"
# リモート（GitHub）に最新の状態を反映
git push origin HEAD
2. タグの作成とPush
次に、バージョン番号をタグとして刻みます。一般的には「Semantic Versioning（セマンティックバージョニング）」に従い、V1.0.0 のような形式を使います。
# ローカルでタグを作成
git tag V1.0.0
# 作成したタグをGitHubに送信（これを行わないとGitHub側で認識されません）
git push origin V1.0.0
このコマンドを実行した瞬間、GitHubのリポジトリ画面に「1 Tag」という表示が現れます。これで、Web画面での仕上げ作業に入る準備が整いました。
【仕上げ】GUI（GitHub Web UI）でのリリース公開
ここからは、ブラウザ上で「見せ方」を整えていきます。
1. Releases画面へアクセス
リポジトリのトップページ右側にある「Releases」という項目をクリックし、「Draft a new release」を選択します。
一度もリリースしたことがないリポジトリでは、「Releases」の項目にある「Create a new release」をクリックします。
2. タグの紐付け
New release の画面が開くので、「Choose a tag」というボタンから、先ほどCLIでPushした V1.0.0 を選択します。
もしCLIでタグを打ち忘れていても、ここで新規作成することも可能ですが、基本的にはCLIで打ったものを選択するほうが事故が少なくなります。
3. リリースノートの自動生成
ここがGitHub Releasesの真骨頂です。
- Release Title
V1.0.0や、キャッチコピーを添えたタイトルを入力します。 - Generate release notes
このボタンをクリックしてください。前回のタグから今回のタグまでの間にマージされたプルリクエストやコミットが、リストアップされます。
手動で修正が必要な場合は、マークダウン形式で追記しましょう。「何が良くなったのか」をユーザー目線で一言添えるだけで、リリースの価値はぐっと高まります。
4. 公開（Publish）
準備ができたら、「Publish release」をクリックします。
この瞬間、GitHubは自動的にその時点のソースコードを .zip と .tar.gz 形式でアーカイブし、誰でもダウンロードできる状態にしてくれます。
【トラブル対応】誤リリースの「安全な」削除方法
「間違えて古いコードでリリースしてしまった！」「タグの名前を間違えた！」という事態は、プロの現場でも起こり得ます。しかし、GitHubの画面上で「Delete」を押すだけでは不十分な場合があることをご存知でしょうか。
実は、「リリース（公開設定）」を消しても、「タグ（歴史の目印）」は残ってしまうのです。
安全な削除の2ステップ
- CLIでタグを削除する（重要）
- GitHubのWeb画面からはタグの物理削除ができないため、以下のコマンドを打ちます。実行すると、GitHub側では「そのタグに紐付いていたリリース」が自動的に「下書き（Draft）」状態に戻ります。
git push --delete origin v1.0.0- Web画面でDraftを破棄する
- Releases一覧画面に残った「Draft」の編集画面に入り、「Delete」を選択します。
この2段階の手順を踏むことで、リモート環境を汚さずに、完全に「なかったこと」にできます。
リリースは次なる物語へのプロローグ
ここまで、GitHub Releasesの全手順を見てきました。最後に全体フローを整理しておきましょう。
| 役割 | 作業内容 | 使用するツール |
| 土台 | コミット・タグのPush | CLI (Gitコマンド) |
| 装飾 | リリースノート生成 | GUI (GitHub Web) |
| 提供 | 公開 (Publish) | GUI (GitHub Web) |
| 撤収 | タグ削除 → Draft破棄 | CLI & GUI |
リリース作業は、開発の「終わり」ではありません。一つの区切りをつけることで、また次の「思考ログ」を積み上げるための新しいスタートラインに立つことができるのです。
命名規則を統一し、リリースノートを丁寧に書く。その一見地味な作業の積み重ねが、将来の自分やチーム、そして何よりユーザーを助けることになります。
ぜひ、今回の手順を参考に、あなたの「思考ログ」を最高の物語として世界に届けてみてください。
本日も最後までお読みいただきありがとうございました。
それでは、よい開発者ライフを！
