「バージョン 1.2.0 のときのコードを確認したい」「リリース前の状態に戻して検証したい」。開発を続けていると、こうした場面がときどきやってきます。ところがコミット履歴を上から眺めても、どのコミットがリリース時点なのかは分かりません。
そこで使うのが git tag です。特定のコミットに v1.2.0 のような名前を付けておけば、あとからその1点をすぐ呼び出せます。ブランチと違って、タグは付けたコミットから動きません。
この記事では、タグの作り方と2種類のタグの違い、過去のコミットへの付け方、一覧の絞り込み、リモートへの反映、削除と付け替え、そしてタグの時点のコードを取り出す方法まで順番に解説します。
目次
タグは特定のコミットに付ける動かない名前
ブランチもタグも「コミットを指す名前」という点では同じです。違うのは、その後の動き方です。ブランチはコミットするたびに新しいコミットへ移動していきますが、タグは最初に指したコミットに留まり続けます。だからこそ「このバージョンをリリースした時点」という印として使えます。
タグの名前は自由に決められますが、実際には v1.0.0 のようにバージョン番号を付けるのが一般的です。GitHub でリリースを作るときも、このタグが土台になります。
軽量タグと注釈付きタグの違い
Git のタグには2種類あります。オプションを何も付けずに作る軽量タグと、-a を付けて作る注釈付きタグ（annotated tag）です。
軽量タグは、コミットを指すだけの単なる別名です。一方の注釈付きタグは、タグそのものが独立したオブジェクトとして保存され、作成者の名前・メールアドレス・作成日時・メッセージを持ちます。GPG 署名を付けることもできます。
| 項目 | 軽量タグ | 注釈付きタグ（-a） |
|---|---|---|
| 作り方 | git tag v1.0.0 | git tag -a v1.0.0 -m "メッセージ" |
| メッセージ | 持てない | 持てる |
| 作成者・日時 | 記録されない | 記録される |
| GPG 署名 | できない | できる（-s） |
| 向いている用途 | 個人的な一時的な目印 | 公開するリリース |
公開するリリースには注釈付きタグを使うのが推奨されています。「誰がいつ、何のために付けたか」が残るからです。逆に、手元で一時的に「ここが動いていた地点」と印を付けたいだけなら軽量タグで十分です。
タグを作る
いまのコミットにタグを付ける
引数にタグ名を渡すだけで、現在チェックアウトしているコミット（HEAD）にタグが付きます。注釈付きにするなら -a と -m を添えます。
# 軽量タグ
$ git tag v1.0.0
# 注釈付きタグ（メッセージ付き）
$ git tag -a v1.1.0 -m "検索機能を追加したリリース"
# 付いたか確認する
$ git tag
v1.0.0
v1.1.0-m を省いて git tag -a v1.1.0 とすると、コミットのときと同じようにエディターが開いてメッセージを入力できます。
過去のコミットにあとからタグを付ける
「タグを付け忘れたままコミットを進めてしまった」というときは、タグ名のあとにコミットハッシュを渡します。
# 履歴からタグを付けたいコミットを探す
$ git log --oneline -5
9f3c1ab リリースノートを更新
4a71d20 検索フォームのスタイルを調整
28f9e36 検索機能を追加
b5d0c94 READMEを更新
1c7a833 初期化
# 3つ前のコミットに注釈付きタグを付ける
$ git tag -a v0.9.0 28f9e36 -m "検索機能の先行リリース"コミットハッシュのかわりに HEAD~3 のような相対指定や、ブランチ名を渡すこともできます。ブランチ名を渡した場合は、そのブランチの先頭コミットにタグが付きます。
タグを一覧・確認する
git tag は一覧表示にも使います。タグが増えてくると全部は見きれないので、-l（--list）にパターンを渡して絞り込みます。
# v1 系だけを表示する
$ git tag -l "v1.*"
v1.0.0
v1.1.0
# メッセージも一緒に表示する
$ git tag -n
v1.0.0 最初のコミット
v1.1.0 検索機能を追加したリリース個別の中身を見たいときは git show にタグ名を渡します。注釈付きタグなら、タグの作成者・日時・メッセージが表示され、そのあとに指しているコミットの差分が続きます。
$ git show v1.1.0
tag v1.1.0
Tagger: taro <taro@example.com>
Date: Mon Sep 22 10:12:03 2025 +0900
検索機能を追加したリリース
commit 9f3c1ab...（以下、コミットの内容と差分）軽量タグに対して git show を実行すると、タグ自身の情報は持っていないため、いきなりコミットの情報が表示されます。この違いで、どちらのタグなのかを見分けられます。
タグをリモートへ送る
ここが最もつまずきやすいところです。git push はタグを自動では送りません。ブランチを push しても、手元で作ったタグは GitHub 側に現れません。タグ名を明示して push する必要があります。
# タグを1つ送る
$ git push origin v1.1.0
# 手元のタグをまとめて送る
$ git push origin --tags
# push するコミットに関係する注釈付きタグも一緒に送る
$ git push --follow-tags--tags は手元にあるタグを種類を問わず全部送るので、実験用に付けた軽量タグまで公開してしまうことがあります。日常的に使うなら --follow-tags のほうが安全です。こちらは push するコミットの履歴に含まれる注釈付きタグだけを対象にします。
逆にリモートのタグを手元に取り込むときは git fetch --tags を使います。通常の git fetch でも、取得したコミットが指しているタグは付いてきますが、確実に全部そろえたいときは --tags を付けます。
タグを削除する・付け替える
ローカルのタグは -d で削除します。リモートのタグは自動では消えないので、別途 --delete で削除を push します。
# ローカルのタグを削除
$ git tag -d v1.1.0
Deleted tag 'v1.1.0' (was 9f3c1ab)
# リモートのタグを削除
$ git push origin --delete v1.1.0「1つ手前のコミットに付けるつもりだった」という付け替えは、削除してから付け直すのが基本です。-f（--force）で上書きもできますが、すでに push したタグを書き換えると、他の人の手元には古いタグが残ったままになります。公開済みのタグは書き換えず、新しい番号のタグを付けるほうがトラブルになりません。
タグの時点のコードを取り出す
タグを付けておくと、そのバージョンの状態にいつでも戻れます。中身を眺めるだけなら git switch --detach、そこから修正を始めるなら新しいブランチを切ります。
# 中身を確認するだけ（detached HEAD になる）
$ git switch --detach v1.0.0
# v1.0.0 から修正用のブランチを作る
$ git switch -c hotfix/v1.0.1 v1.0.0
# 差分を見るだけならチェックアウトしなくてよい
$ git diff v1.0.0 v1.1.0 --statタグの時点のファイル一式を ZIP などで書き出したいときは git archive が使えます。git archive --format=zip -o v1.0.0.zip v1.0.0 のように実行すると、そのタグの時点のファイルだけがアーカイブされます。.git ディレクトリは含まれません。
タグがうまく扱えないときの確認ポイント
GitHub にタグが表示されない
ほとんどの場合、タグを push していないだけです。前述のとおり git push はタグを送らないので、git push origin <タグ名> を実行してください。リモートにあるタグを確認したいときは git ls-remote --tags origin で一覧を取得できます。手元の git tag の結果と見比べれば、送れているかどうかがはっきりします。
タグをチェックアウトしたら detached HEAD と言われた
これはエラーではありません。タグはブランチと違って動かない名前なので、そこにチェックアウトすると「どのブランチにも乗っていない状態」になります。これが detached HEAD です。この状態でコミットしても、どのブランチからも辿れないコミットができてしまうので、修正を加えるなら git switch -c <新しいブランチ名> でブランチを作ってから作業します。
削除したはずのタグが復活する
ローカルだけ削除してリモートに残っている状態で git fetch --tags を実行すると、また戻ってきます。タグを完全になくしたいなら、ローカルとリモートの両方で削除してください。チームで作業している場合は、他のメンバーの手元にも残っているので、削除したことを共有する必要があります。
すでに同じ名前のタグがあると言われる
fatal: tag 'v1.0.0' already exists と表示されたら、その名前のタグがすでに存在しています。git show v1.0.0 でどのコミットを指しているか確認し、本当に付け替えたい場合だけ削除してから作り直してください。うっかり -f で上書きすると、リリース番号と中身の対応が崩れてしまいます。
まとめ
git tag は、リリースした時点のコミットに動かない名前を付けておくためのコマンドです。公開するリリースには git tag -a v1.0.0 -m "メッセージ" で注釈付きタグを付け、手元の一時的な目印には軽量タグを使う、という分け方をしておけば迷いません。
一番の注意点は、タグが git push で自動的には送られないことです。タグを付けたら git push origin <タグ名> を忘れずに実行するか、--follow-tags を習慣にしてください。削除も同じで、ローカルとリモートで別々の操作が必要です。
タグを付けておけば、git switch -c hotfix v1.0.0 でそのバージョンから修正ブランチを切ったり、git diff v1.0.0 v1.1.0 でバージョン間の差分を確認したりできます。リリースのたびに1コマンド実行しておくだけで、あとの調査がずいぶん楽になります。