【Git】git tag push でタグを反映する方法を初心者向けにわかりやすく解説
はじめに
皆さんは開発をしているときに「このタイミングでのソースコードをわかりやすく記録しておきたい」と感じることはないでしょうか。
特にプロジェクトが大きくなるほど、いつ・どの段階のコードだったのかを管理するのが難しくなってきます。
そこで便利なのが git tag という機能です。
このタグを手元(ローカル)だけでなくリモートにも反映させるために使うのが git tag push です。
タグを用いると、あらかじめ「バージョン番号」や「リリース時点」を明確に記録しておくことができます。
チームでコードを共有する場合でも、特定の時点をすぐに参照できるため便利です。
本記事では git tag push の基本的な使い方から、実務でどのように活用できるのかまで説明します。
この記事を読むとわかること
- git tag push の全体像と使い方
- タグを使うメリットや具体的なコマンド例
- 実務での具体的な活用シーン
- バージョン管理でよく使われるタグ運用のポイント
git tag pushとは
git tag push は、ローカルリポジトリで作成したタグをリモートリポジトリへ反映するコマンドです。
タグとは、「このコミットはリリース版1.0.0に対応している」といったように、重要な区切りをわかりやすく管理するためにつけるラベルのようなものです。
実務では、たとえばプロダクトのリリース時点や重要なマイルストーンのタイミングでタグを作成し、あとで振り返るときに役立てます。
ポイントとしては、タグをつけた後に忘れずにプッシュする必要がある、というところです。
ローカルだけにタグをつけても、リモートには反映されません。
そのため、チーム開発などで共有したい場合には git tag push が不可欠になります。
gitでタグを使うメリット
タグはコミットと似ていますが、あくまでも「特定のコミットに目印をつける」機能のため、次のようなメリットがあります。
リリースやバージョンの明確化
どのコミットがどのリリースに該当するのかを明確にできます。 コミットIDだと理解しづらい場合でも、タグなら「v1.0.0」など人間がわかりやすい名前を設定できます。
重要なポイントに素早くアクセスできる
過去の状態を再現するときに、タグを使うと簡単にチェックアウトできます。 これにより不具合が発生したときなど、特定のコミットを探す手間を減らすことができます。
チームでの連携がスムーズになる
いま開発しているコードのバージョンがどこなのか、メンバー全員が同じ認識を持てます。 タグをリモートリポジトリで共有すれば、メンバー同士でのやりとりがしやすくなります。
git tag pushの基本的な流れ
タグの作成
まずはローカルリポジトリでタグを作成します。
新しいタグを付与するときは、以下のように git tag コマンドを使います。
git tag v1.0.0
このコマンドを実行すると、現在チェックアウトしているコミット(つまり最新のコミット)に「v1.0.0」という名前のタグを作成できます。
もし、すでに過去のコミットに対してタグを付けたい場合は、以下のようにコミットIDを指定します。
git tag v1.0.0 <コミットID>
このように指定すれば、特定のコミットへタグを付与できます。
タグをリモートへプッシュする
作成したタグをリモートにプッシュするために、 git push origin <タグ名>
のように指定します。
git push origin v1.0.0
この操作によって、リモートリポジトリにタグが反映されます。
もし複数のタグがある場合、まとめてプッシュしたいときは以下のように --tags オプションを使う方法もあります。
git push origin --tags
ただし、あまり大量のタグを一気にプッシュすると、不要なタグまでリモートにアップされる可能性があります。
本当に必要なタグだけを共有する場合は、個別に指定した方がわかりやすいでしょう。
タグの一覧を確認する
タグの一覧は、次のコマンドで確認できます。
git tag --list
たとえば、タグ名に関して部分一致で検索するには次のようにします。
git tag --list "v1.*"
「v1.」で始まるタグだけリストアップしたいときに便利です。
タグの種類:軽量タグと注釈付きタグ
gitのタグには大きく分けて「軽量タグ」と「注釈付きタグ」の2種類があります。
軽量タグ(lightweight tag)
ただコミットに名前をつけるだけのタグ。 メッセージや作成者情報などを含まないため、簡単につけられる一方で追加情報を残せません。
注釈付きタグ(annotated tag)
メッセージや作成者情報、日付などをタグとあわせて記録できます。 公式ドキュメントでは、こちらが推奨されていますが、あくまで必要に応じて使い分けると良いでしょう。
たとえば注釈付きタグを作成したいときは、以下のようなコマンドを使います。
git tag -a v1.0.0 -m "リリース初回版"
このタグをプッシュする場合は、やはり git push origin v1.0.0 が必要になります。
実務での活用シーン
リリースタイミングの管理
開発しているアプリケーションをリリースするとき、コミットIDだけで管理していると、後から振り返るときに不便なことがあります。
タグを打っておけば、たとえば「v1.0.0」「v1.1.0」「v1.2.0」のようにリリースごとに明確な目印を残せます。
チーム内で「v1.1.0はどのコミットなんだろう?」といった疑問もすぐに解消できるでしょう。
ロールバックの効率化
万が一リリース後に不具合が見つかった場合、タグを使って簡単に過去の状態に戻すことができます。
git checkout v1.0.0
このようにすれば、v1.0.0時点のコードに切り替えられます。
もし一時的に不具合を回避するために過去バージョンに戻る必要があるとき、タグを使っておけば素早く対応できます。
CI/CDと連携するとき
継続的インテグレーション(CI)や継続的デプロイメント(CD)を利用するときに、タグをトリガーとしてビルドやデプロイを実行できることがあります。
たとえば「v1.0.0」タグがプッシュされたら自動的にビルドを走らせてリリースするといったフローを構築するケースです。
git tag push を使ってリモートにタグを送ることで、CI/CDツールが「新しいバージョンが追加された」と認識し、自動でビルドがスタートします。
このように自動化と相性がよい点も、タグの大きなメリットです。
タグを削除したい場合
ローカルタグの削除
万が一、タグを誤ってつけてしまった場合や、不要になった場合はローカルで削除できます。
git tag -d v1.0.0
上のコマンドを実行すると、ローカルに存在する「v1.0.0」タグが消えます。
リモートタグの削除
リモートにも既にプッシュしていた場合は、以下のようなコマンドを使うことでリモート上のタグを削除できます。
git push origin :v1.0.0
これは少し独特な書き方ですが、:v1.0.0
と指定することで「v1.0.0タグを空にする」イメージになります。
なお、リモートのタグを削除してしまうと、チーム開発の場合は他の人の作業に影響が出ることも考えられます。
削除するときは慎重に行いましょう。
git tag pushで気をつけたいポイント
コミットが存在しない場合
タグを付与するコミットが存在しない状態だとエラーになったり、意図しない結果になることがあります。
必ず、コードをコミットしてからタグをつけるようにしましょう。
同じ名前のタグに注意
既に存在するタグ名を再度付けようとすると、意図しない衝突や混乱が起きるかもしれません。
タグ名は一意になるように工夫するのが基本です。
タグのメッセージ管理
注釈付きタグを利用する場合は、メッセージを丁寧に書いておくと、あとから確認しやすくなります。
「どのようなリリースなのか」「何が変わったのか」といった内容を簡潔に残しておくと、メンバー全員の理解がスムーズに進むでしょう。
複数のリリースを頻繁に行うプロジェクトでは、タグ名の付け方をあらかじめチームで決めておくと混乱を防ぎやすいです。
チーム開発とgit tag push
チーム開発では、各メンバーがそれぞれのローカルリポジトリでコミットを作成します。
大事なリリースタイミングになったら、代表者がタグを打って git tag push でリモートに登録し、全員がそのタグを共有する形を取ることが多いです。
このとき、「誰が」「いつ」「どういう意図で」タグを作ったのかを周知しておくと、後々のトラブルを防ぐことにも繋がります。
また、チーム内でGitフローを導入している場合、リリースブランチを作ってからタグを打つ運用をしているところもあります。
いずれにせよ、タグはあくまで「わかりやすい指標」として使うという点が重要です。
コミット単位で動くGitにおいて、タグはコミットIDより親切な名前を割り当てる仕組みだと考えましょう。
トラブルシューティング
タグをプッシュしても他の人が見えないとき
タグを作成して git push origin v1.0.0 を忘れている可能性が考えられます。
ローカルで作っただけでは他の人は見えませんので、必ずタグをプッシュするようにしてください。
あるいは「--tags」オプションでまとめて送っても構いません。
リモートタグの取得
他のメンバーがプッシュしたタグが自分のローカルで確認できない場合は、以下のコマンドで取得できます。
git fetch --all --prune --tags
「git fetch」だけではタグを取得しない場合もあるので、明示的に --tags を指定するのがおすすめです。
複数の環境での運用
個人開発であれば問題ありませんが、複数の環境(開発・ステージング・本番)を分けて運用する場合は、同じタグを使い回さないようにすることが多いです。
たとえば本番リリース時には「release-YYYYMMDD」形式のタグをつけるなど、チームで明確なルールを設けておくと混乱を減らせます。
タグ名のルールを決めておくと、複数プロジェクトやステージング環境との連携で作業がスムーズに進みやすいです。
まとめ
ここまで git tag push の基本から実務での活用シーン、運用時の注意点などを解説しました。
タグを使うことで、開発の節目をわかりやすく整理できるので、チームでの共同作業にも役立ちます。
バージョンを明確に示すことでリリース管理もしやすくなり、プロジェクト全体のスムーズな進行につながります。
ぜひ今回ご紹介した内容を参考に、皆さんのプロジェクトでも上手にタグを活用してみてください。