【Git】git push tag でタグ付けするやり方を初心者向けにわかりやすく解説
はじめに
ソフトウェア開発では、管理するコードのバージョンが増えていくため、どの時点のソースがどういう状態なのかを把握することが大切です。
そのようなときにタグという仕組みを使うと、ある特定のコミットを指し示して「この時点を重要なマイルストーンとして扱う」というような目印をつけることができます。
本記事では、git push tag の使い方を中心に、そもそもタグとは何なのか、作成の手順や実務での活かし方を初心者向けにわかりやすく説明します。
この記事を読むとわかること
- Gitタグの基本的な役割
- タグの作成と使い方
- git push tag を使ってリモートリポジトリにタグを反映させる手順
- 実務におけるタグの活用シーンと注意点
Gitタグとは何か
Gitタグは、特定のコミットに対して目印をつけるための機能です。
一般的には、リリースのタイミングやマイルストーンとなるコミットなどにタグを付与し、管理しやすくします。
また、タグを使えば「このタグが付いたコミットからビルドを行う」といった明確な基準づくりに役立ちます。
Gitタグとブランチの違い
ブランチは、開発を進めるための分岐点のような役割を持ちます。
対してタグは、ブランチのように先に進むのではなく、あるコミットを固定的に参照するためのものです。
つまりブランチは継続的にコミットが積み重なる可能性がありますが、タグは過去の特定のコミットを「この場所を大事に残しておく」イメージで固定します。
ブランチ運用の中でも「このリリースの状態を後から振り返りたい」という場合、タグをつけておけばコミットの参照が容易になります。
タグを作成する方法
タグを作るには、注釈付きタグと軽量タグの2種類があります。
いずれの方法も簡単ですが、注釈付きタグを利用するとタグにコメントや作成者などの情報を含められるため、重要度が高いマイルストーンには注釈付きのほうが便利です。
注釈付きタグと軽量タグ
注釈付きタグ
タグを作成した日時やコメント、作成者情報などを含めることができます。コミット履歴を人間が見たときに情報を把握しやすくなる点がメリットです。
軽量タグ
単純にコミットをタグ名で参照できるようにするだけの簡易的なタグです。余計なメタ情報が必要ない場合に選択します。
タグ作成時の具体例
まずは注釈付きタグの作り方から確認しましょう。 以下のコマンドでタグを作成します。
# 注釈付きタグの例 git tag -a v1.0 -m "初回リリース用のタグ"
-a v1.0 はタグ名を v1.0 として作る指定です。
-m "初回リリース用のタグ" では、そのタグにメッセージを付けています。
一方、軽量タグの場合は次のように作成します。
# 軽量タグの例 git tag v1.0-light
この場合、メッセージなどの詳細情報は含まれません。 ただし、コミットを指す固定的な目印として利用する点は同じです。
タグをリモートにプッシュする方法
ローカルリポジトリにタグを作成しただけでは、タグの情報はリモートリポジトリには反映されません。
そこで登場するのがgit push tag という考え方です。
厳密には git push origin <tag名> のように指定したり、 git push origin --tags のようにすべてのタグをまとめてプッシュしたりします。
git push tag について
タグをリモートにプッシュする代表的なコマンド例を挙げます。
# 特定のタグをリモートにプッシュする git push origin v1.0
これはローカルで作成した v1.0 という名前のタグをリモートリポジトリに送るコマンドです。 これによって、他の開発者もリモートから v1.0 タグを取得できます。
もし、いくつものタグを一斉にプッシュしたいなら、次のように --tags を使ってまとめてプッシュできます。
# ローカルにあるすべてのタグをプッシュする git push origin --tags
なお、git push tag というコマンドそのものが存在するわけではありませんが、実質的には「タグをプッシュする」という意図でよく検索されるキーワードといえるでしょう。
プッシュされる仕組み
Gitでは、リモートにまだ存在しないタグをプッシュすると、リモートがそのタグ情報を新たに取得します。
一度リモートにタグを作ってしまえば、他の開発者が git fetch --tags や単純な git fetch を行うだけでタグ情報を取得可能です。
つまりローカルで作ったマイルストーンをリモートで共有する重要な作業が、git push tag という形で呼ばれる一連の操作に当たります。
実務での活用シーン
タグの魅力は、具体的な運用シーンでさらに光ってきます。 いくつか代表的なケースを見ていきましょう。
リリース管理
多くの開発現場では、機能開発やバグ修正がひと段落したタイミングでリリースを行います。 ここで「v1.0」や「release-2023-02」のような形でタグをつけておくと、そのリリース時点のソースコードを簡単に参照できます。
リリース後に問題が発覚しても、タグが示すコミットにすぐ戻れるので、原因箇所を特定しやすいのが利点です。
デプロイフローとの関連
デプロイ作業で「あるタグが付いたコミットを本番環境に配置する」というフローを採用しているチームもあります。 たとえば、自動化されたCI/CDツールを導入していると、タグ付きのコミットをトリガーにしてビルドやデプロイを実行する仕組みも組みやすくなります。
このようにタグは「どのタイミングのソースコードを本番へ適用するか」を明確に管理する上で欠かせない存在です。
よくあるトラブルシューティング
初心者の方が最初に直面しやすいトラブルを見てみましょう。
タグがリモートに表示されない
ローカルでタグを作ったのに、リモートリポジトリ上のタグ一覧には見当たらないというパターンです。
これは単純にプッシュを忘れていることが多いため、 git push origin <tag名> もしくは git push origin --tags を実行してみましょう。
タグはあくまでもローカルで作られた情報であり、明示的にプッシュしないとリモートには反映されない点に注意が必要です。
その他、同じタグ名が既に存在していたり、プッシュするリモート先を誤っているケースもあります。 原因に応じて、リモート先の設定が正しいかを確認するといいでしょう。
まとめ
ここまで、Gitのタグ機能や作り方、git push tag と呼ばれる手順について解説しました。
タグを利用すると、リリース管理やデプロイ時に非常に便利です。 ブランチのように先へ進むわけではなく、あくまでも過去を示す目印なので、過去の状態に素早くアクセスできるようになります。
特にリリース版ごとにタグを付けておく運用は多くの現場で導入されています。 これをうまく活用することでソースの混乱を防げるでしょう。
もし複数のタグをまとめてプッシュしたい場合には git push origin --tags を使ってみてください。
また、特定のタグだけをプッシュしたい場合は git push origin v1.0 のように指定するとよいです。
以上を踏まえると、git push tag はコマンドそのものではないですが、「タグをリモートにプッシュする」という動作の総称として認識すると理解しやすいかもしれません。
皆さんも、ぜひ必要に応じてタグを作り、git push tag の流れでリモートに反映してみてください。