
本記事の目的
本記事は、バージョン管理システムGitと、コラボレーションプラットフォームGitHubを、体系的に学び、実践的に使いこなすためのガイドです。
あなたがGitユーザーとして、チームの生産性とコードの品質を牽引できる、信頼される開発者へと成長することができる情報を提供します。
コミットが日々の細かな変更を記録する「日記」だとすれば、この記事で学ぶ「タグ」は、その歴史における重要な節目を示す「章のタイトル」や「巻数」のようなものです。
タグを使うことで、「バージョン1.0」や「ベータ版リリース」といった、後から誰もが参照できる目印をコミット履歴に付けることができます。そして、GitHubの「リリース」機能と連携することで、目印だけでなく、ユーザー向けの成果物(実行ファイルなど)を配布する正式なバージョン情報として公開できます。
目次
- 操作の概要:プロダクトに「バージョン1.0」のラベルを貼るまでの流れ
- ステップ1:プロダクトを完成させる(リリースの準備)
- ステップ2:完成品にバージョンシール「タグ」を貼る(
git tag
) - ステップ3:「タグ」をチーム全体に共有する(
git push
) - ステップ4:プロダクトの提供物、説明書を添えて公開する(
gh release create
)
- コマンド解説:タグとリリースを使いこなす
- 参考資料
- まとめ
対象読者
本書は、以下の読者を対象としています。
- GitやGitHubをこれから学びたい、あるいは学び始めたばかりの学生や初学者の方
- 黒い画面(ターミナル)に抵抗がある方でも、一つひとつのコマンドの意味と目的を理解しながら、着実にステップアップできます。
- 自己流でGitを使ってきたが、チーム開発の経験は浅いエンジニアの方
- Pull Requestの作成、コードレビュー、コンフリクトの解決といった、共同作業で必須となる作法を体系的に学び直したい方に最適です。
- GitHubの便利な機能を使いこなし、開発プロセスを改善したい中級者の方
- GitHub ActionsによるCI/CDの構築、セキュリティ機能の導入、CODEOWNERSによる責任範囲の明確化など、チームの生産性と安全性を向上させるための具体的な手法を学べます。
- エンジニアと協業する非エンジニア職(デザイナー、プロジェクトマネージャー、テクニカルライター等)の方
- 開発チームがどのようなツールとプロセスで仕事を進めているのかを理解し、より円滑なコミュニケーションとコラボレーションを実現するための知識を得られます。
操作の概要:プロダクトに「バージョン1.0」のラベルを貼るまでの流れ
ソフトウェアのリリースは、開発したプロダクトをユーザーに届けるためのプロセスです。
ここでは、リリースまでの一連の流れを、4つのステップで解説します。
各ステップの詳しいコマンド操作は、後述の「コマンド解説」セクションで確認してください。
ステップ1:プロダクトを完成させる(リリースの準備)
まず、開発してきたソフトウェアが「リリースできる」状態になっていることが大前提です。
例えば、以下のような状態です。
- 新機能の開発が完了し、テストも通過。
main
ブランチが、ユーザーに自信を持って届けられる「完成品」の状態になった。
ステップ2:完成品にバージョンシール「タグ」を貼る(git tag
)
次に、この「完成品」がいつの時点のコードなのか、誰が見てもわかるようにタグという目印を付けます。
例えば、「これがバージョン1.0だ」と、リリースするソースコードの時間軸(区切りとするコミット)を明確に示します。
ステップ3:「タグ」をチーム全体に共有する(git push
)
自分のPC(ローカル)でタグを付けても、その情報はまだ他の開発者やGitHubには伝わっていません。
次に、ローカルで作成したv1.0
タグを、チーム全員が見られるGitHub(リモートリポジトリ)に送信します。
ステップ4:プロダクトの提供物、説明書を添えて公開する(gh release create
)
最後に、タグを付けたバージョンを、ユーザー向けの公式な「リリース」として公開します。
GitHub上で、v1.0
タグに基づいたリリースノート(変更点の一覧)を作成し、必要であれば提供物(実行ファイルなど)を添付して、ユーザーがダウンロードできるようにします。
今回の作業には、Github CLIを使います。インストール手順は、以下の記事で詳細に解説していますので是非ご覧ください。
コマンド解説:タグとリリースを使いこなす
1. git tag
:貼られた「タグ」(バージョンシール)の一覧を見る
目的:
これまでに作成されたタグ(バージョンシール)を一覧で確認します。
利用シーン:
- 「今までにどんなバージョンがリリースされたんだっけ?」と過去の履歴を確認したいとき。
- 次に付けるべきバージョン番号を決めるとき(例:「v1.2.0」の次だから「v1.3.0」にしよう)。
実行例と結果:
コマンド例 :
ターミナルで git tag
と入力します。すると、今までのタグが表示されます。
hogehoge@mac hello-world % git tag
v0.0.0
v0.0.1
v0.0.2
v0.0.3
v0.0.3a
v0.0.5
hogehoge@mac hello-world %
このように、作成済みのタグがアルファベット順に表示されます。
2. git tag -a <タグ名> -m "メッセージ"
:情報付きの「タグ」を貼る(推奨)
目的:
「誰が、いつ、なぜ」付けたのかというプロダクトのリリースに関する情報を含んだ、公式なタグ(注釈付きタグ)を作成します。プロダクトのバージョン管理において推奨される方法です。
利用シーン:
- プロダクトの公式バージョン(
v1.0.0
など)をリリースするとき。 - 関係者にテストを依頼するベータ版(
v1.1.0-beta
など)を明確にしたいとき。
コマンド解説:
git tag -a <タグ名>
:-a
(annotate) は「注釈を付ける」という意味です。<タグ名>
にはv1.3.0
のようなバージョン番号を指定します。-m "メッセージ"
:-m
(message) は、このタグが何であるかを説明するメッセージ(例:「ユーザー管理機能を追加した新バージョン」)を記録するためのものです。git tag -d <タグ名>
: タグを削除するコマンドです。ローカルリポジトリから指定したタグを消去します。git show <タグ名>
: タグが指し示すコミットの情報を表示します。コミットメッセージ、差分などを確認できます。
実行例と結果:
コマンド例 :
- まず、リリース対象のブランチ(通常は
main
)を最新の状態にします。
$ git switch main
$ git pull
- タグを作成します。成功した場合、通常は何もメッセージは表示されません。
$ git tag -a v1.3.0 -m "ユーザー管理機能を追加した新バージョン"
git tag
で確認すると、新しいタグが追加されています。
$ git tag
v0.1.0
v1.0.0
v1.1.0
v1.2.0
v1.3.0 # <- 新しく追加された!
コマンドの実行例:タグ付け(臨時バージョンの場合)
# タグ付け前
hogehoge@mac hello-world % git tag
v0.0.0
v0.0.1
v0.0.2
v0.0.3
v0.0.3a
v0.0.5
# タグ付け
hogehoge@mac hello-world % git tag -a v0.0.5a -m "バグ修正した臨時バージョン"
# タグ付け後
hogehoge@mac hello-world % git tag
v0.0.0
v0.0.1
v0.0.2
v0.0.3
v0.0.3a
v0.0.5
v0.0.5a
hogehoge@mac hello-world %
コマンドの実行例:タグの詳細確認
hogehoge@mac hello-world % git show v1.3.0
tag v1.3.0
Tagger: hogehoge <hogehoge@example.com>
Date: Wed Sep 10 13:44:25 2025 +0900
ユーザー管理機能を追加した新バージョン
commit b0d07f3900207fbd4cd106517f1d3a739a02e1a8 (**HEAD** -> **feature/main**, **tag: v1.3.0**)
Author: hogehoge <hogehoge@example.com>
Date: Mon Sep 8 18:47:23 2025 +0900
Revert "upd:add fifth line"
This reverts commit 193b0cde8e5e9eec4f3974a790145b3ced3a2e6f.
**diff --git a/README.md b/README.md**
**index d212eb8..0e12795 100644**
**--- a/README.md**
**+++ b/README.md**
@@ -2,4 +2,3 @@
add second line
add third line
add fourth line
-add fifth line
hogehoge@mac hello-world %
ポイント:
- チームで共有する公式なリリースには、後から意図が明確にわかるこの注釈付きタグを必ず使いましょう。
- 過去のコミットに付けたい場合:
git log --oneline
で目的のコミットID(例:f4a1b2c
)を調べ、コマンドの最後に付け加えます。
git tag -a v1.2.1 -m "緊急バグ修正" f4a1b2c
3. git tag <タグ名>
:軽量タグを使う(個人作業用)
目的:
詳細情報を含まない、シンプルなタグ(軽量タグ)を作成します。
利用シーン:
- 公式リリースではなく、自分だけが後で参照したい箇所に一時的な目印を付けたいとき。
- 「後でこの部分のコードを見直そう」といった、個人的なメモ代わりに。
実行例と結果:
コマンド例 :
$ git tag temp-fix
コマンドの実行例:タグ付け(個人的に作業の目印にタグをつける場合)
# 作業対象のタグを追加
hogehoge@mac hello-world % git tag temp-fix
hogehoge@mac hello-world % git tag
temp-fix
# 作業実施
hogehoge@mac hello-world % vi README.md
hogehoge@mac hello-world % vi index.html
# 作業が終わったのでタグを削除
hogehoge@mac hello-world % git tag -d temp-fix
Deleted tag 'temp-fix' (was b0d07f3)
hogehoge@mac hello-world %
ポイント:
- 誰がいつ付けたかの情報が残らないため、個人的な用途に限定するのが一般的です。チームで共有する公式なタグには使わないようにしましょう。
4. git push origin <タグ名>
:「タグ」をチーム全体に公開する
目的:
自分のPC(ローカル)で作成したタグを、GitHub(リモートリポジトリ)にアップロードしてチーム全体に共有します。
利用シーン:
- ローカルで作成した公式リリース用のタグ
v1.3.0
を、GitHubに反映させて他のメンバーに知らせたいとき。
コマンド解説:
git push origin <タグ名>
: 特定のタグを1つだけプッシュします。これが最も安全で確実な方法です。git push origin --tags
: ローカルにある全ての未プッシュのタグを、まとめてプッシュします。意図しないタグまでプッシュしてしまう可能性があるので、利用には注意が必要です。
実行例と結果:
コマンド例 :
$ git push origin v1.3.0
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:your-name/your-repo.git
* [new tag] v1.3.0 -> v1.3.0
[new tag]
と表示されれば、無事にGitHubへ送信された証拠です。
コマンドの実行例:タグ付けとGithubへのプッシュ
# タグ付けと状態の確認
hogehoge@mac hello-world % git tag -a v1.3.0 -m "ユーザー管理機能を追加した新バージョン"
hogehoge@mac hello-world % git tag
v1.3.0
hogehoge@mac hello-world % git status
On branch feature/main
nothing to commit, working tree clean
# Githubへプッシュ
hogehoge@mac hello-world % git push origin v1.3.0
Enter passphrase for key '/Users/hogehoge/.ssh/id_ed25519':
Enumerating objects: 13, done.
Counting objects: 100% (13/13), done.
Delta compression using up to 8 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (11/11), 1.07 KiB | 1.07 MiB/s, done.
Total 11 (delta 3), reused 0 (delta 0), pack-reused 0 (from 0)
remote: Resolving deltas: 100% (3/3), done.
To github.com:hogehoge/hello-world.git
* [new tag] v1.3.0 -> v1.3.0 #[new tag]が出力されていれば成功
hogehoge@mac hello-world %
ポイント:
- 超重要: 一度プッシュしたタグを安易に変更・削除するのは避けましょう。他の人がそのタグを基準に作業を始めている可能性があり、チームに混乱を招きます。プッシュ前には、タグ名や対象コミットが正しいか必ず確認してください。
- 補足: 万が一、プッシュしたタグを削除する必要がある場合は、まずローカルでタグを削除 (
git tag -d <タグ名>
) し、その後リモートリポジトリから削除 (git push origin --delete <タグ名>
) します。ただし、この操作はチームに混乱を招く可能性があるため、実行前に必ずチームで合意形成を行ってください。
5. gh release create <タグ名>
:プロダクトを公開する
目的:
GitHubの「リリース」ページを作成し、ユーザー向けに成果物を分かりやすく公開します。これはGit本体ではなく、GitHub CLI (gh
) という専用ツールの機能です。
利用シーン:
- 新バージョンのソフトウェアを、ユーザーがダウンロードできる形で公開したいとき。
- 今回のバージョンアップで何が変わったのかを「リリースノート」として綺麗にまとめて公開したいとき。
コマンド解説:
gh release create <タグ名>
: 指定したタグを元に、対話形式でリリース情報(タイトル、説明文など)を作成できます。--generate-notes
: (超便利!) 前回のリリースから今回のタグまでのコミットメッセージを元に、変更点の一覧(リリースノート)を自動で生成してくれます。--title "タイトル"
: リリースのタイトルを直接指定します。--notes "説明文"
: リリースの説明文を直接指定します。
実行例と結果:
コマンド例 :
# v1.3.0タグを元に、リリースノートを自動生成して公開
$ gh release create v1.3.0 --generate-notes
コマンドの実行例:タグ付けとGithubへのプッシュ
(gh
コマンドのインストールとgh auth login
での認証が事前に必要です)
hogehoge@mac hello-world % gh release create v1.3.0 --generate-notes
https://github.com/orcus-s13i-tbp/hello-world/releases/tag/v1.3.0
hogehoge@mac hello-world %
コマンドを実行するとURLが出力され、ブラウザでリリースのページを確認することができます。
ポイント:
git tag
がコードの歴史に目印を付ける開発者向けの内部的な行為だとすれば、gh release create
は、その目印を元にユーザー向けに成果物を「お披露目」する外部的な行為です。この違いを理解しておきましょう。
参考資料
- Pro Git Book – Gitの基本 タグ
- https://git-scm.com/book/ja/v2/Git-の基本-タグ
- GitHub Docs – リリースについて
- https://docs.github.com/ja/repositories/releasing-projects-on-github/about-releases
まとめ
本記事では、Gitの「タグ」とGitHubの「リリース」機能について学びました。
コミットが日々の進捗を記録する「日記」なら、タグとリリースはプロジェクトの歴史における「重要な章の完成」を宣言する行為です。
この二つの機能を使いこなすことで、ソフトウェアのバージョンは明確に管理され、チームメンバーやユーザーとのコミュニケーションも円滑になります。
ぜひ、あなたのプロジェクトでも次のマイルストーンに到達した際に、最初のタグを打ち、リリースを作成してみてください。
さあ、あなたのMacを快適な開発環境にしましょう!!