あなたは、自分が書いたコードの「あのバージョン」に、一瞬で戻りたいと思ったことはありませんか？あるいは、チームメンバーに「この機能が完成したバージョンです」と、自信を持ってソースコードを共有したいと思ったことは？
本記事では、そんなあなたのための「タイムマシン」機能、GitのタグとGitHubのリリースについて、どこよりも分かりやすく解説します。
この記事を読み終える頃には、あなたはソフトウェアのバージョンを自在に操り、チームからの信頼も厚い、ワンランク上の開発者へと成長しているはずです。
目次
タグとリリースの全体像：バージョン1.0を公開するまでの4ステップ
ソフトウェアのリリースは、開発したプロダクトをユーザーに届けるための重要なプロセスです。
ここでは、リリースまでの一連の流れを、4つのステップで解説します。
各ステップの詳しいコマンド操作は、後述の「コマンド解説」セクションで確認してください。
ステップ1：リリースする製品（コード）を準備する
まず、開発してきたソフトウェアが「リリースできる」状態になっていることが大前提です。
例えば、以下のような状態です。
- 新機能の開発が完了し、テストも通過。
mainブランチが、ユーザーに自信を持って届けられる「完成品」の状態になった。
ステップ2：git tagでバージョン番号の「タグ」を付ける
次に、この「完成品」がいつの時点のコードなのか、誰が見てもわかるようにタグという目印を付けます。
例えば、「これがバージョン1.0だ」と、リリースするソースコードの時間軸（区切りとするコミット）を明確に示します。
ステップ3：git pushでタグをチームに共有する
自分のPC（ローカル）でタグを付けても、その情報はまだ他の開発者やGitHubには伝わっていません。
次に、ローカルで作成したv1.0タグを、チーム全員が見られるGitHub（リモートリポジトリ）に送信します。
ステップ4：GitHubリリースを作成し、ユーザーに公開する
最後に、タグを付けたバージョンを、ユーザー向けの公式な「リリース」として公開します。
GitHub上で、v1.0タグに基づいたリリースノート（変更点の一覧）を作成し、必要であれば提供物（実行ファイルなど）を添付して、ユーザーがダウンロードできるようにします。
Github CLI(gh)の導入や使い方については、以下の記事で詳細に解説していますので、是非ご覧ください。
【コマンド別】git tag と GitHubリリースの使い方
1. git tag：過去のタグ（バージョン）一覧を確認する
目的:
これまでに作成されたタグ（バージョンシール）を一覧で確認します。
利用シーン:
- 「今までにどんなバージョンがリリースされたんだっけ？」と過去の履歴を確認したいとき。
- 次に付けるべきバージョン番号を決めるとき（例：「v1.2.0」の次だから「v1.3.0」にしよう）。
実行例と結果:
コマンド例 :
ターミナルで git tag と入力します。すると、今までのタグが表示されます。
your-name@mac hello-world % git tag
v0.0.0
v0.0.1
v0.0.2
v0.0.3
v0.0.3a
v0.0.5
your-name@mac hello-world %このように、作成済みのタグがアルファベット順に表示されます。
理解度チェック
Q.git tagで表示されるタグの順番は？
A. アルファベット順（数値も文字として扱われます）
2. git tag -a：公式リリースで必須！「注釈付きタグ」の作成方法
目的:
「誰が、いつ、なぜ」付けたのかというプロダクトのリリースに関する情報を含んだ、公式なタグ（注釈付きタグ）を作成します。プロダクトのバージョン管理において推奨される方法です。
利用シーン:
- プロダクトの公式バージョン（
v1.0.0など）をリリースするとき。 - 関係者にテストを依頼するベータ版（
v1.1.0-betaなど）を明確にしたいとき。
コマンド解説:
git tag -a <タグ名>:-a(annotate) は「注釈を付ける」という意味です。<タグ名>にはv1.3.0のようなバージョン番号を指定します。-m "メッセージ":-m(message) は、このタグが何であるかを説明するメッセージ（例：「ユーザー管理機能を追加した新バージョン」）を記録するためのものです。git tag -d <タグ名>: タグを削除するコマンドです。ローカルリポジトリから指定したタグを消去します。git show <タグ名>: タグが指し示すコミットの情報を表示します。コミットメッセージ、差分などを確認できます。
実行例と結果:
コマンド例 :
- まず、リリース対象のブランチ（通常は
main）を最新の状態にします。
$ git switch main
$ git pull- タグを作成します。成功した場合、通常は何もメッセージは表示されません。
# v1.3.0という注釈付きタグを作成
$ git tag -a v1.3.0 -m "ユーザー管理機能を追加した新バージョン"git tagで確認すると、新しいタグが追加されています。
$ git tag
v0.1.0
v1.0.0
v1.1.0
v1.2.0
v1.3.0 # <- 新しく追加された！コマンドの実行例：タグ付け（臨時バージョンの場合）
# タグ付け前
your-name@mac hello-world % git tag
v0.0.0
v0.0.1
v0.0.2
v0.0.3
v0.0.3a
v0.0.5
# タグ付け
your-name@mac hello-world % git tag -a v0.0.5a -m "バグ修正した臨時バージョン"
# タグ付け後
your-name@mac hello-world % git tag
v0.0.0
v0.0.1
v0.0.2
v0.0.3
v0.0.3a
v0.0.5
v0.0.5a
your-name@mac hello-world %コマンドの実行例：タグの詳細確認
your-name@mac hello-world % git show v1.3.0
tag v1.3.0
Tagger: your-name <your-name@example.com>
Date: Wed Sep 10 13:44:25 2025 +0900
ユーザー管理機能を追加した新バージョン
commit b0d07f3900207fbd4cd106517f1d3a739a02e1a8 (**HEAD** -> **feature/main**, **tag: v1.3.0**)
Author: your-name <your-name@example.com>
Date: Mon Sep 8 18:47:23 2025 +0900
Revert "upd:add fifth line"
This reverts commit 193b0cde8e5e9eec4f3974a790145b3ced3a2e6f.
**diff --git a/README.md b/README.md**
**index d212eb8..0e12795 100644**
**--- a/README.md**
**+++ b/README.md**
@@ -2,4 +2,3 @@
add second line
add third line
add fourth line
-add fifth line
your-name@mac hello-world %ポイント:
- チームで共有する公式なリリースには、後から意図が明確にわかるこの注釈付きタグを必ず使いましょう。
- 過去のコミットに付けたい場合:
git log --onelineで目的のコミットID（例:f4a1b2c）を調べ、コマンドの最後に付け加えます。
git tag -a v1.2.1 -m "緊急バグ修正" f4a1b2cやってみよう！
git log --onelineを実行して、最新のコミットから2番目のコミットのIDを調べてみましょう。そして、そのコミットに対してv1.0.0-testという名前の注釈付きタグを付けてみてください。メッセージは自由です！
3. git tag：個人メモ用の「軽量タグ」をサクッと作る
目的:
詳細情報を含まない、シンプルなタグ（軽量タグ）を作成します。
利用シーン:
- 公式リリースではなく、自分だけが後で参照したい箇所に一時的な目印を付けたいとき。
- 「後でこの部分のコードを見直そう」といった、個人的なメモ代わりに。
実行例と結果:
コマンド例 :
$ git tag temp-fixコマンドの実行例：タグ付け（個人的に作業の目印にタグをつける場合）
# 作業対象のタグを追加
your-name@mac hello-world % git tag temp-fix
your-name@mac hello-world % git tag
temp-fix
# 作業実施
your-name@mac hello-world % vi README.md
your-name@mac hello-world % vi index.html
# 作業が終わったのでタグを削除
your-name@mac hello-world % git tag -d temp-fix
Deleted tag 'temp-fix' (was b0d07f3)
your-name@mac hello-world %ポイント:
- 誰がいつ付けたかの情報が残らないため、個人的な用途に限定するのが一般的です。チームで共有する公式なタグには使わないようにしましょう。
理解度チェック
Q. チームの公式リリースに「軽量タグ」を使ってはいけないのはなぜ？
A. 「誰が」「いつ」付けたかの情報が残らず、責任の所在や経緯が不明確になるため。
4. git push origin <タグ名>：作成したタグをGitHubにプッシュ（共有）する
目的:
自分のPC（ローカル）で作成したタグを、GitHub（リモートリポジトリ）にアップロードしてチーム全体に共有します。
利用シーン:
- ローカルで作成した公式リリース用のタグ
v1.3.0を、GitHubに反映させて他のメンバーに知らせたいとき。
コマンド解説:
git push origin <タグ名>: 特定のタグを1つだけプッシュします。これが最も安全で確実な方法です。git push origin --tags: ローカルにある全ての未プッシュのタグを、まとめてプッシュします。意図しないタグまでプッシュしてしまう可能性があるので、利用には注意が必要です。
実行例と結果:
コマンド例 :
$ git push origin v1.3.0
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:your-name/your-repo.git
* [new tag] v1.3.0 -> v1.3.0[new tag] と表示されれば、無事にGitHubへ送信された証拠です。
コマンドの実行例：タグ付けとGithubへのプッシュ
# タグ付けと状態の確認
your-name@mac hello-world % git tag -a v1.3.0 -m "ユーザー管理機能を追加した新バージョン"
your-name@mac hello-world % git tag
v1.3.0
your-name@mac hello-world % git status
On branch feature/main
nothing to commit, working tree clean
# Githubへプッシュ
your-name@mac hello-world % git push origin v1.3.0
Enter passphrase for key '/Users/your-name/.ssh/id_ed25519':
Enumerating objects: 13, done.
Counting objects: 100% (13/13), done.
Delta compression using up to 8 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (11/11), 1.07 KiB | 1.07 MiB/s, done.
Total 11 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (3/3), done.
To github.com:your-name/hello-world.git
* [new tag] v1.3.0 -> v1.3.0 #[new tag]が出力されていれば成功
your-name@mac hello-world %ポイント:
- 超重要: 一度プッシュしたタグを安易に変更・削除するのは避けましょう。他の人がそのタグを基準に作業を始めている可能性があり、チームに混乱を招きます。（何を隠そう、私も新人時代に
--tagsオプションでテスト用のタグを大量にプッシュしてしまい、開発リーダーにこっぴどく叱られた苦い経験があります…）。プッシュ前には、タグ名や対象コミットが正しいか必ず確認してください。 - 補足: 万が一、プッシュしたタグを削除する必要がある場合は、まずローカルでタグを削除 (
git tag -d <タグ名>) し、その後リモートリポジトリから削除 (git push origin --delete <タグ名>) します。ただし、この操作はチームに混乱を招く可能性があるため、実行前に必ずチームで合意形成を行ってください。
5. gh release create：リリースノートを自動生成して公開する
目的:
GitHubの「リリース」ページを作成し、ユーザー向けに成果物を分かりやすく公開します。これはGit本体ではなく、GitHub CLI (gh) という専用ツールの機能です。
利用シーン:
- 新バージョンのソフトウェアを、ユーザーがダウンロードできる形で公開したいとき。
- 今回のバージョンアップで何が変わったのかを「リリースノート」として綺麗にまとめて公開したいとき。
コマンド解説:
gh release create <タグ名>: 指定したタグを元に、対話形式でリリース情報（タイトル、説明文など）を作成できます。--generate-notes: （超便利！） 前回のリリースから今回のタグまでのコミットメッセージを元に、変更点の一覧（リリースノート）を自動で生成してくれます。--title "タイトル": リリースのタイトルを直接指定します。--notes "説明文": リリースの説明文を直接指定します。
実行例と結果:
コマンド例 :
# v1.3.0タグを元に、リリースノートを自動生成して公開
$ gh release create v1.3.0 --generate-notesコマンドの実行例：タグ付けとGithubへのプッシュ
（ghコマンドのインストールとgh auth loginでの認証が事前に必要です）
your-name@mac hello-world % gh release create v1.3.0 --generate-notes
https://github.com/orcus-s13i-tbp/hello-world/releases/tag/v1.3.0
your-name@mac hello-world %コマンドを実行するとURLが出力され、ブラウザでリリースのページを確認することができます。
ポイント:
git tagがコードの歴史に目印を付ける開発者向けの内部的な行為だとすれば、gh release createは、その目印を元にユーザー向けに成果物を「お披露目」する外部的な行為です。この違いを理解しておきましょう。
理解度チェック
Q.gh release createの--generate-notesオプションを使うと、どんないいことがありますか？
A. 前回のリリースから今回のタグまでのコミットメッセージを元に、変更点の一覧（リリースノート）を自動で生成してくれるため、リリースノート作成の手間が大幅に省けます。
【補足】セマンティックバージョニングとは？
タグを付ける際、v1.0.0やv1.3.0といったバージョン番号をどのように決めれば良いか迷うかもしれません。多くのプロジェクトでは、「セマンティックバージョニング」というルールが採用されています。
これは、メジャー.マイナー.パッチ（例: 1.4.2）という3つの数字でバージョンを管理する規約です。
- メジャー (1.x.x): 後方互換性のない大きな変更（例: 大規模なUI変更、APIの仕様変更）があった場合に増やします。
- マイナー (x.4.x): 後方互換性のある機能追加（例: 新しいボタンの追加）があった場合に増やします。
- パッチ (x.x.2): 後方互換性のあるバグ修正（例: 誤字の修正、軽微な表示崩れ）があった場合に増やします。
このルールに従うことで、バージョン番号を見るだけで「今回の変更はどのくらい大きいのか」が誰にでも伝わるようになります。
まとめ：バージョン管理を新たなレベルへ
本記事では、Gitの「タグ」とGitHubの「リリース」を使い、ソフトウェアのバージョンを管理する方法を学びました。
- タグ (
git tag): コミット履歴上の重要な点に「目印」を付ける開発者向けの機能。 - プッシュ (
git push origin <タグ名>): ローカルで付けたタグを、チームで共有するためにリモートへ送信する。 - リリース (
gh release create): タグを元に、ユーザー向けの「公式バージョン」として成果物や変更履歴を公開する。
これらの機能を使いこなすことは、単なる技術習得以上の意味を持ちます。それは、あなたのソフトウェアの歴史を丁寧に紡ぎ、ユーザーやチームへの責任を果たすという、プロフェッショナルな開発者の証です。
本記事をご利用いただくにあたって
この記事は、公開時点（2025年9月）の情報に基づき、正確な情報を提供するよう努めています。
しかし、本記事で解説するソフトウェアやサービスの仕様は日々更新されるため、記事内で紹介している画面や手順が、ご覧いただいている時点では変更されている可能性があります。
もし内容に相違がある場合は、各サービスの最新の公式ドキュメントも併せてご参照ください。本記事の情報を利用される際は、ご自身の判断と責任においてお願いいたします。
