Gitタグの使い方入門：リリース版を迷子にしないための基本
Gitタグは、特定のコミットに「v1.0.0」「release-2026-07-08」のような名前を付けて、あとから同じ地点を確実に参照するための目印です。
ブランチが日々進む作業場所だとすれば、タグは「この時点をリリース版として固定する」ためのラベルです。WordPressテーマの更新、静的サイトの公開、サーバー設定ファイルの変更、自動デプロイの起点管理で役立ちます。
この記事では、Gitタグを実務で使う理由、基本コマンド、入力例と出力例、よくある失敗、ブランチやCHANGELOGとの使い分けを整理します。
- Gitタグは、特定のコミットを後から探しやすくする固定ラベル
- リリース版、納品版、復旧ポイント、デプロイ対象の管理に向いている
- 基本は
git tag、git tag -a、git push origin <tag>を押さえる - ローカルで作ったタグは、自動ではリモートへ送られない
- 実務では、タグ名のルールを先に決めると運用が崩れにくい
Gitタグは「あとで戻れる公開地点」を作る仕組み
Gitタグの役割は、変化し続ける履歴の中で、重要な1点を名前で固定することです。
たとえばWordPressテーマを更新するとき、main ブランチには修正コミットが増えていきます。数日後に「本番へ出した版はどれだったか」を探す場合、コミットIDだけでは読みづらく、Slackや作業メモに残した番号も散らばりがちです。
そこで、公開したコミットに次のようなタグを付けます。
git tag -a v1.2.0 -m "Release v1.2.0"
これで、そのコミットを v1.2.0 という名前で参照できます。
git show v1.2.0
コミットIDを覚えなくても、公開時点の差分、作者、日時、メッセージを確認できます。
ここがポイント: タグは「作業を続ける場所」ではなく、「この時点を後から同じ名前で見つけるための目印」です。
タグが効く場面
実務では、次のような場面でタグが便利です。
- WordPressテーマやプラグインのリリース版を残す
- サーバー設定変更前の状態を復旧ポイントとして残す
- 自動デプロイで「このタグが付いたら本番へ反映する」と決める
- 納品時点のソースコードを後から確認できるようにする
- CHANGELOGの
v1.2.0とGit上の実体を結びつける
重要なのは、タグを付けるだけで安心しないことです。チームで使うなら、タグをリモートリポジトリへ送る必要があります。
前提環境：この記事で使うGitコマンド
ここでは、Git公式ドキュメントで案内されている基本的なタグ操作を前提にします。Gitのタグ機能自体は長く使われている基本機能ですが、実行環境によって表示や既定ブランチ名は異なる場合があります。
この記事の例では、次の前提で説明します。
- OS: Windows、macOS、Linuxのいずれでも考え方は同じ
- ツール: Git CLI
- リモート名:
origin - 作業ブランチ例:
main - タグ名例:
v1.0.0、v1.1.0
Gitが使えるか確認するには、ターミナルで次を実行します。
git --version
出力例です。
git version 2.45.0
バージョン番号は環境によって違って問題ありません。コマンドが見つからない場合は、GitのインストールやPATH設定を先に確認してください。
タグには「軽量タグ」と「注釈付きタグ」がある
Gitタグには大きく分けて、軽量タグと注釈付きタグがあります。実務でリリース版を残すなら、まずは注釈付きタグを使うと管理しやすくなります。
軽量タグは短い目印
軽量タグは、指定したコミットへのシンプルな参照です。
git tag v1.0.0
作成済みタグを一覧表示します。
git tag
出力例です。
v1.0.0
個人作業や一時的な目印なら軽量タグでも足ります。ただし、誰がどんな意図で付けたタグかを残したい場面には弱いです。
注釈付きタグはリリース記録に向いている
注釈付きタグは、タグ作成者、日時、メッセージなどの情報を持つタグです。
git tag -a v1.0.0 -m "Release v1.0.0"
タグの内容を確認します。
git show v1.0.0
出力例のイメージです。
tag v1.0.0
Tagger: Taro Example <taro@example.com>
Date: Wed Jul 8 10:00:00 2026 +0900
Release v1.0.0
commit 8f3a2c1...
Author: Taro Example <taro@example.com>
リリース、納品、検証済み版のように、後から説明責任が発生しやすい地点には注釈付きタグが向いています。
| 種類 | 作り方 | 向いている場面 |
|---|---|---|
| 軽量タグ | git tag v1.0.0 |
個人作業の短い目印、一時確認 |
| 注釈付きタグ | git tag -a v1.0.0 -m "Release v1.0.0" |
リリース版、納品版、チーム運用 |
基本の書き方：作成、確認、リモート送信
Gitタグで最初に覚える操作は、作る、見る、送る、消す、の4つです。
タグを作成する
現在のコミットに注釈付きタグを付ける例です。
git tag -a v1.0.0 -m "Release v1.0.0"
過去のコミットにタグを付けたい場合は、コミットIDを指定します。
git tag -a v1.0.0 8f3a2c1 -m "Release v1.0.0"
この書き方は、リリース後にタグを付け忘れたときに使います。ただし、どのコミットが実際に公開されたものかを確認してから実行してください。
タグ一覧を確認する
git tag
条件に合うタグだけを表示することもできます。
git tag -l "v1.*"
出力例です。
v1.0.0
v1.1.0
v1.2.0
タグをリモートへ送る
ローカルでタグを作っても、それだけではGitHubやGitLabなどのリモートには反映されません。
git push origin v1.0.0
複数のタグをまとめて送る場合は、次のコマンドを使えます。
git push origin --tags
ただし、意図しない古いタグまで送ってしまうことがあります。実務では、リリース対象のタグを1つずつ指定して送るほうが確認しやすいです。
タグを削除する
ローカルのタグを削除します。
git tag -d v1.0.0
リモートのタグを削除します。
git push origin --delete v1.0.0
一度共有したタグを削除・作り直しすると、ほかのメンバーや自動デプロイに影響します。公開済みタグの変更は、チーム内で合意してから行うのが安全です。
入力例と出力例：WordPressテーマをリリースする流れ
ここでは、WordPressテーマの v1.1.0 を公開する場面で、タグを使う流れを見ます。
1. 状態を確認する
git status
出力例です。
On branch main
nothing to commit, working tree clean
作業ツリーがきれいな状態でタグを付けると、「どの変更が含まれていたか」が追いやすくなります。未コミットの変更が残っていると、その内容はタグに含まれません。
2. 直近の履歴を確認する
git log --oneline -5
出力例です。
8f3a2c1 Fix header menu on mobile
4b91a7d Update theme stylesheet version
0a7d552 Add footer navigation
この例では、8f3a2c1 をリリース対象にします。
3. タグを作成する
git tag -a v1.1.0 -m "Release v1.1.0"
4. タグを確認する
git show v1.1.0
出力から、タグがどのコミットを指しているか確認します。
tag v1.1.0
Tagger: Taro Example <taro@example.com>
Release v1.1.0
commit 8f3a2c1...
5. リモートへ送る
git push origin v1.1.0
ここまで行うと、チームメンバーやCI/CDツールが v1.1.0 を参照できるようになります。
実務での使いどころ：タグは「人」と「自動化」の共通目印になる
タグの価値は、コマンドそのものよりも、運用の中で同じ地点を共有できることにあります。
リリース履歴とソースコードをつなぐ
CHANGELOGに次のような記録を書いたとします。
## v1.1.0 - 2026-07-08
- スマホ表示時のヘッダーメニューを修正
- テーマCSSのバージョン表記を更新
Gitにも同じ v1.1.0 タグがあれば、文章上の変更履歴と実際のソースコードが結びつきます。
「CHANGELOGには書いてあるが、どのコミットなのか分からない」という状態を避けられます。
自動デプロイの起点にする
サーバー運用では、タグをデプロイの合図にすることがあります。
たとえば、次のようなルールです。
mainへのpushだけでは本番反映しないv*のタグがpushされたときだけ本番デプロイするv1.1.0のようなタグ名をリリース版として扱う
この方法にすると、通常の開発コミットと本番公開のタイミングを分けられます。GitHub ActionsなどのCI/CDでも、タグpushをトリガーにする設定がよく使われます。
復旧や比較の基準にする
障害調査では、「今の状態」と「前回リリース時点」を比べることがあります。
git diff v1.0.0..v1.1.0
このコマンドで、v1.0.0 から v1.1.0 までに入った変更を確認できます。
サーバー側で問題が出たとき、タグがあれば「どの版に戻すか」「どの差分を疑うか」を決めやすくなります。
よくある失敗と対処法
Gitタグでつまずきやすい点は、タグがブランチのように自動で動くと思ってしまうことです。タグは基本的に固定された目印です。
タグを作ったのにGitHubに表示されない
原因は、ローカルで作ったタグをリモートへpushしていないことが多いです。
NG例です。
git tag -a v1.0.0 -m "Release v1.0.0"
git push origin main
main をpushしても、タグは自動では送られません。
改善例です。
git push origin v1.0.0
複数タグをまとめて送る必要があるときだけ、--tags を検討します。
タグ名を後から変えたくなる
タグ名の変更は、実際には削除して作り直す操作になります。
git tag -d v1.0.0
git tag -a v1.0.1 -m "Release v1.0.1"
git push origin --delete v1.0.0
git push origin v1.0.1
公開済みタグを作り直すと、すでにそのタグを取得している人の環境とずれる場合があります。リリース後に番号を間違えたときは、削除して隠すより、次の正しいタグを作るほうが安全なケースもあります。
タグを付けるコミットを間違える
タグは現在のコミットに付くため、作業ブランチやHEADの位置を確認せずに実行すると、意図しない地点に付くことがあります。
作成前に確認するコマンドです。
git branch --show-current
git log --oneline -3
必要であれば、コミットIDを明示してタグを付けます。
git tag -a v1.2.0 8f3a2c1 -m "Release v1.2.0"
タグ名のルールがばらばらになる
v1.0、1.0.0、release_1_0_0 が混ざると、自動化や検索で扱いにくくなります。
最初に次のようなルールを決めると、運用が安定します。
- リリース版は
v1.2.3形式にする - 検証用は
test-20260708のように本番用と分ける - 本番デプロイ対象は
vで始まるタグだけにする - 一度公開したタグは原則として作り直さない
バージョン番号には、Semantic Versioningの考え方を参考にできます。必ず完全採用する必要はありませんが、MAJOR.MINOR.PATCH の区切りを使うと、変更の大きさを伝えやすくなります。
ブランチ、コミット、タグ、リリースの違い
初心者が混乱しやすいのは、タグとブランチの違いです。どちらもコミットを指しますが、目的が違います。
| 項目 | 役割 | 実務での使い方 |
|---|---|---|
| コミット | 変更の記録 | 1つの修正、追加、削除を履歴として残す |
| ブランチ | 作業の流れ | 機能追加、修正、検証を並行して進める |
| タグ | 固定された目印 | リリース版、納品版、復旧ポイントを示す |
| リリース | 配布・公開単位 | GitHub Releasesなどで説明文や成果物を付ける |
ブランチは新しいコミットが増えると先へ進みます。一方、タグは基本的に同じコミットを指し続けます。
そのため、開発作業にはブランチ、公開済み地点の記録にはタグ、利用者向けの説明や配布ファイルにはリリース、という分け方が分かりやすいです。
最小運用ルール：小さく始めるならこれで十分
Gitタグは細かく設計しすぎると、初心者チームでは続かなくなります。まずは、リリース時に同じ流れを毎回再現できる状態を目指すのが現実的です。
小さく始めるなら、次のルールで十分です。
- リリース時だけ注釈付きタグを作る
- タグ名は
v1.2.3形式にそろえる - タグ作成前に
git statusとgit log --oneline -3を確認する - 作成後に
git show <tag>で指しているコミットを見る - リモートへは
git push origin <tag>で1つずつ送る - 公開済みタグは原則として作り直さない
このルールなら、WordPressテーマの更新、LP制作の納品、サーバー設定の変更管理、自動デプロイの起点づくりまで使い回せます。
最後に、作業前のチェックリストを置いておきます。
- 今いるブランチは正しいか
- 未コミットの変更は残っていないか
- タグを付けるコミットは公開・納品したい内容か
- タグ名は既存ルールと合っているか
- リモートへpushする必要があるか
- CHANGELOGやリリースノートの番号と一致しているか
Gitタグは、派手な機能ではありません。しかし、あとから「どの版を出したのか」を確認する場面では強い味方になります。次に見るべきポイントは、タグ名のルールとデプロイ条件が一致しているかです。そこがずれると、タグは目印ではなく、別の混乱の入口になります。