タグとリリース（tag）

「このコミットが v1.0.0 として世に出したバージョンだ」という目印を付けたいとき、Gitではタグを使います。軽量タグと注釈付きタグの違い、v1.2.3のようなバージョン番号の付け方の慣習、そしてタグはpushしないとリモートに反映されない点まで、リリース管理の基本を押さえます。

コミットには自動でハッシュ値（3a9f1c2 のような英数字）が振られるが、これは人間にとって覚えやすいものではない。「あのコミットがリリースしたバージョンだったよね」というとき、ハッシュを覚えている人はまずいない。

ブランチ名で管理する方法も考えられるが、ブランチは日々の作業のために新しいコミットが積まれ続ける、動き続ける存在だ。「この一点で固定して残しておきたい」というリリースの目的には向かない。

そこでコミットに人間が読める名札を付ける仕組みがタグだ。git tag v1.0.0 のように打つと、今のコミットに v1.0.0 という名前が付き、以後はハッシュの代わりにこの名前で参照できるようになる。

🏷️ 軽量タグと注釈付きタグ

タグには2種類ある。軽量タグ（lightweight tag）と、注釈付きタグ（annotated tag）だ。

軽量タグは git tag v1.0.0 のように名前だけを付ける、シンプルな付箋のようなものだ。作成者やメッセージの情報を持たない。

注釈付きタグは git tag -a v1.0.0 -m "最初の安定版" のように -a と -m を付けて作る。作成者・日付・メッセージを持つ、独立したオブジェクトとして記録される。

🔢 v1.2.3 という数字の意味

バージョン番号には v1.2.3 のように3つの数字を使う慣習が広く使われている。これはセマンティックバージョニング（semver）と呼ばれる考え方で、それぞれの数字に意味がある。

1つ目（メジャー）は、これまでの使い方と互換性のない大きな変更をしたときに上げる。2つ目（マイナー）は、互換性を保ったまま機能を追加したときに上げる。3つ目（パッチ）は、バグ修正など小さな直しをしたときに上げる。

📤 push --tags を忘れずに

タグは、git push を普通に実行しただけではリモートに送られない。コミットとタグは別物として扱われるため、タグを共有したいときは明示的に push する必要がある。

手元に複数のタグがあり、まとめて送りたいときは --tags オプションを使う。

🔍 タグの時点を見に行く

過去のリリース時点のコードを見たいときは git checkout v1.0.0 とすると、そのタグが指すコミットの状態にファイルが切り替わる。

たとえば「本番でv1.0.0にだけ出ている不具合を、その時点のコードで再現して直したい」という場面では、まずタグを checkout して状況を確認し、修正が必要と分かった時点で新しいブランチを切って作業する、という流れが安全だ。

タグを使えるようになると、「あのバージョンのコードはどうなっていたか」をいつでも正確に呼び出せるようになる。リリースのたびにタグを打つ習慣は、あとから自分を助ける小さな保険だ。

小さな個人開発であっても、区切りのよいところでタグを打っておくと、「動いていた最後の地点」に迷わず戻れる安心感がある。コミットを重ねるだけでなく、節目にしおりを挟む発想を持っておきたい。

🧹 タグの削除と付け間違い

タグを付け間違えた、あるいは不要になったという場合もある。ローカルのタグを消すには git tag -d タグ名 を使う。

📋 タグの一覧と絞り込み

作成済みのタグを見るには git tag だけで一覧が出るが、数が増えてくると絞り込みたくなる。git tag -l "v1.*" のようにパターンを指定すると、条件に合うタグだけを表示できる。

❓ ブランチとタグ、何が違うのか

初心者がよく混同するのがブランチとタグの違いだ。ブランチは「今後もコミットが積まれていく、動く先端」であるのに対し、タグは「その瞬間で止まった、動かない目印」という違いがある。

リリースブランチという運用スタイルもあるが、それとタグは役割が異なる。リリースブランチは「そのバージョン専用の修正を続ける場所」、タグは「公開した瞬間そのものの記録」と考えると整理しやすい。両方を組み合わせて、大きな修正はブランチで、公開の記録はタグで、という使い分けをするプロジェクトも多い。

この項目に出てくる用語

関連コマンド

▶ 学習アプリでこの続きを学ぶ・演習する