日本語 ▾ トピック ▾ 最新バージョン ▾ git-tag は 2.46.0 で最終更新されました

名前

git-tag - GPGで署名されたタグオブジェクトを作成、リスト表示、削除、または検証する

概要

git tag [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] [-e]
	[(--trailer <token>[(=|:)<value>])…​]
	<tagname> [<commit> | <object>]
git tag -d <tagname>…​
git tag [-n[<num>]] -l [--contains <commit>] [--no-contains <commit>]
	[--points-at <object>] [--column[=<options>] | --no-column]
	[--create-reflog] [--sort=<key>] [--format=<format>]
	[--merged <commit>] [--no-merged <commit>] [<pattern>…​]
git tag -v [--format=<format>] <tagname>…​

説明

`-d/-l/-v` を指定してタグを削除、リスト表示、または検証する場合を除き、`refs/tags/` にタグ参照を追加します。

`-f` が指定されていない限り、指定されたタグはまだ存在してはいけません。

`-a`、`-s`、または `-u <key-id>` のいずれかが渡されると、コマンドはタグオブジェクトを作成し、タグメッセージを必要とします。`-m <msg>` または `-F <file>` が指定されていない限り、ユーザーがタグメッセージを入力するためにエディターが起動されます。

`-m <msg>` または `-F <file>` または `--trailer <token>[=<value>]` が指定され、`-a`、`-s`、および `-u <key-id>` がない場合、`-a` が暗示されます。

それ以外の場合、指定されたオブジェクトを直接指すタグ参照 (すなわち軽量タグ) が作成されます。

`-s` または `-u <key-id>` が使用されると、GnuPG署名付きタグオブジェクトが作成されます。`-u <key-id>` が使用されない場合、現在のユーザーのコミッターIDが署名用のGnuPGキーを見つけるために使用されます。設定変数 `gpg.program` は、カスタムのGnuPGバイナリを指定するために使用されます。

タグオブジェクト (`-a`、`-s`、または `-u` で作成) は「annotated (注釈付き)」タグと呼ばれます。これらは作成日、タグ作成者名とメールアドレス、タグ付けメッセージ、およびオプションのGnuPG署名を含みます。一方、「lightweight (軽量)」タグは単にオブジェクト (通常はコミットオブジェクト) の名前です。

注釈付きタグはリリース用であり、軽量タグはプライベートまたは一時的なオブジェクトラベル用です。このため、オブジェクトに名前を付ける一部のgitコマンド (git describe など) は、デフォルトで軽量タグを無視します。

オプション

-a
--annotate

署名なしの、注釈付きタグオブジェクトを作成する

-s
--sign

デフォルトのメールアドレスのキーを使用して、GPG署名付きタグを作成します。タグのGPG署名のデフォルトの動作は、tag.gpgSign 設定変数が存在する場合はそれによって制御され、それ以外の場合は無効になります。git-config[1] を参照してください。

--no-sign

すべてのタグに署名を強制するように設定されている tag.gpgSign 設定変数を上書きします。

-u <key-id>
--local-user=<key-id>

指定されたキーを使用して、GPG署名付きタグを作成します。

-f
--force

既存のタグを指定された名前で置き換えます (失敗する代わりに)

-d
--delete

指定された名前の既存のタグを削除します。

-v
--verify

指定されたタグ名のGPG署名を検証します。

-n<num>

`-l` を使用する際に、注釈から (もしあれば) 何行表示するかを `` で指定します。`--list` を暗示します。

デフォルトでは、注釈行は何も表示されません。`-n` に数字が指定されない場合、最初の行のみが表示されます。タグに注釈がない場合、代わりにコミットメッセージが表示されます。

-l
--list

タグをリスト表示します。オプションの <pattern>... を使用すると、例えば git tag --list 'v-*' のように、パターンに一致するタグのみをリスト表示します。

引数なしで「git tag」を実行すると、すべてのタグもリスト表示されます。パターンはシェルワイルドカード (つまり、fnmatch(3) を使用してマッチングされます) です。複数のパターンを指定できます。いずれかに一致する場合、タグが表示されます。

このオプションは、--contains のような他のリスト表示関連オプションが指定された場合、暗黙的に提供されます。詳細については、各オプションのドキュメントを参照してください。

--sort=<key>

指定されたキーに基づいてソートします。値の降順でソートするには - をプレフィックスとして付けます。--sort=<key> オプションを複数回使用でき、その場合、最後のキーが主キーになります。「version:refname」または「v:refname」もサポートします (タグ名はバージョンとして扱われます)。「version:refname」のソート順は「versionsort.suffix」設定変数によっても影響を受ける可能性があります。サポートされるキーは git for-each-ref のものと同じです。ソート順は、tag.sort 変数が存在する場合はその設定値に、それ以外の場合は辞書順にデフォルト設定されます。git-config[1] を参照してください。

--color[=<when>]

`--format` オプションで指定された色を尊重します。`` フィールドは always、never、または auto のいずれかでなければなりません (もし `` が省略された場合、always が指定されたものとして動作します)。

-i
--ignore-case

タグのソートとフィルタリングは大文字と小文字を区別しません。

--omit-empty

フォーマットが空文字列に展開されるフォーマット済みの参照の後に改行を出力しません。

--column[=<options>]
--no-column

タグのリストを列で表示します。オプションの構文については、設定変数 column.tag を参照してください。オプションなしの --column と --no-column は、それぞれ always と never に相当します。

このオプションは、注釈行なしでタグをリスト表示する場合にのみ適用可能です。

--contains [<commit>]

指定されたコミット (指定がない場合はHEAD) を含むタグのみをリスト表示します。--list を暗示します。

--no-contains [<commit>]

指定されたコミット (指定がない場合はHEAD) を含まないタグのみをリスト表示します。--list を暗示します。

--merged [<commit>]

指定されたコミット (指定がない場合はHEAD) から到達可能なコミットを持つタグのみをリスト表示します。

--no-merged [<commit>]

指定されたコミット (指定がない場合はHEAD) から到達可能でないコミットを持つタグのみをリスト表示します。

--points-at <object>

指定されたオブジェクトのタグのみをリスト表示します (指定がない場合はHEAD)。--list を暗示します。

-m <msg>
--message=<msg>

指定されたタグメッセージを使用します (プロンプト表示の代わりに)。複数の -m オプションが指定された場合、それらの値は別々の段落として連結されます。`-a`、`-s`、または `-u <key-id>` のいずれも指定されていない場合、`-a` が暗示されます。

-F <file>
--file=<file>

指定されたファイルからタグメッセージを読み込みます。標準入力からメッセージを読み込むには - を使用します。`-a`、`-s`、または `-u <key-id>` のいずれも指定されていない場合、`-a` が暗示されます。

--trailer <token>[(=|:)<value>]

トレーラーとして適用されるべき (<token>, <value>) ペアを指定します。(例: git tag --trailer "Custom-Key: value" はタグメッセージに「Custom-Key」トレーラーを追加します。) trailer.* 設定変数 (git-interpret-trailers[1]) を使用して、重複するトレーラーを省略するかどうか、各トレーラーがトレーラーの実行のどこに表示されるか、その他の詳細を定義できます。トレーラーは git tag --list で --format="%(trailers)" プレースホルダーを使用して抽出できます。

-e
--edit

`-F` でファイルから、`-m` でコマンドラインから取得したメッセージは通常、タグメッセージとして変更されずに使用されます。このオプションを使用すると、これらのソースから取得したメッセージをさらに編集できます。

--cleanup=<mode>

このオプションは、タグメッセージのクリーンアップ方法を設定します。<mode> は verbatim、whitespace、strip のいずれかです。strip モードがデフォルトです。verbatim モードはメッセージを全く変更せず、whitespace は行頭/行末の空白行のみを削除し、strip は空白とコメントの両方を削除します。

--create-reflog

タグのreflogを作成します。タグのreflogをグローバルに有効にするには、git-config[1] の core.logAllRefUpdates を参照してください。否定形式の --no-create-reflog は、以前の --create-reflog を上書きするだけであり、現在のところ core.logAllRefUpdates の設定を無効にするものではありません。

--format=<format>

表示されているタグ参照とそれが指すオブジェクトから %(fieldname) を補間する文字列です。フォーマットは git-for-each-ref[1] と同じです。指定がない場合、%(refname:strip=2) がデフォルトとなります。

<tagname>

作成、削除、または説明するタグの名前です。新しいタグ名は、git-check-ref-format[1] で定義されているすべてのチェックに合格する必要があります。これらのチェックの中には、タグ名に使用できる文字を制限するものもあります。

<commit>
<object>

新しいタグが参照するオブジェクトで、通常はコミットです。デフォルトはHEADです。

設定

デフォルトでは、署名デフォルトモード (`-s`) の git tag は、キーを見つけるためにあなたのコミッターID (`Your Name <your@email.address>` の形式) を使用します。異なるデフォルトキーを使用したい場合は、リポジトリ設定で次のように指定できます

[user]
    signingKey = <gpg-key-id>

pager.tag は、タグをリスト表示する場合、つまり -l が使用されるか暗示される場合にのみ尊重されます。デフォルトはページャーを使用することです。git-config[1] を参照してください。

考察

タグの再設定について

誤ったコミットにタグを付けてしまい、タグを再設定したい場合はどうすればよいでしょうか？

何もプッシュしていない場合は、単にタグを再設定してください。古いタグを置き換えるには「-f」を使用します。これで完了です。

しかし、すでにプッシュしてしまった場合 (または、他の人があなたのリポジトリを直接読み取れる場合)、他の人はすでに古いタグを見ています。その場合、次の2つのうちのいずれかを行うことができます

  1. 賢明な方法。間違いを認め、異なる名前を使用します。他の人はすでにそのタグ名を見ています。同じ名前を使い続けると、2人の人が両方とも「バージョンX」を持っているが、実際には異なる「X」を持っているという状況になるかもしれません。したがって、「X.1」と呼んでそれを終わりにしてください。

  2. 非常識な方法。他の人が古いバージョンをすでに見ていても、新しいバージョンも「X」と呼びたい場合です。その場合、古いバージョンをまだ公開していないかのように、再度 git tag -f を使用してください。

ただし、Gitはユーザーの知らないうちにタグを変更しません (また、そうすべきではありません)。したがって、誰かがすでに古いタグを取得している場合、あなたのツリーで git pull を実行しても、古いタグが上書きされるべきではありません。

誰かがあなたからリリースタグを取得した場合、あなたが自身のタグを更新するだけで、その人のタグを変更することはできません。これは大きなセキュリティ問題であり、人々はタグ名を信頼できなければなりません。もし本当に非常識なことをしたいのであれば、素直に間違いを認め、その旨を人々に伝える必要があります。それは、次のような非常に公的な発表をすることで行えます

Ok, I messed up, and I pushed out an earlier version tagged as X. I
then fixed something, and retagged the *fixed* tree as X again.

If you got the wrong tag, and want the new one, please delete
the old one and fetch the new one by doing:

	git tag -d X
	git fetch origin tag X

to get my updated tag.

You can test which tag you have by doing

	git rev-parse X

which should return 0123456789abcdef.. if you have the new version.

Sorry for the inconvenience.

これは少し複雑に思えますか？ そうであるべきです。これを自動的に「修正」するのが正しい方法であるはずがありません。人々は、自分のタグが変更された可能性があることを知る必要があります。

自動追従について

他の人のツリーを追従している場合、おそらくリモート追跡ブランチ (例: refs/remotes/origin/master) を使用しているでしょう。通常、相手側のタグも取得したいはずです。

一方で、誰かからのワンショットマージを望んでフェッチしている場合、通常、そこからタグを取得したいとは思いません。これはトップレベルに近い人々によく起こりますが、彼らに限定されるものではありません。一般のユーザーが互いにプルする場合、相手のプライベートなアンカーポイントタグを自動的に取得したいとは限りません。

メーリングリストでの「pullしてください」というメッセージは、通常、リポジトリのURLとブランチ名の2つの情報しか提供しません。これは git fetch コマンドラインの末尾に簡単にカット＆ペーストできるように設計されています

Linus, please pull from

	git://git..../proj.git master

to get the following updates...

は次のように変換されます

$ git pull git://git..../proj.git master

このような場合、相手のタグを自動的に追従したくないでしょう。

Gitの重要な側面の1つは、その分散性です。これは、システム内に本質的な「アップストリーム」や「ダウンストリーム」が存在しないことを大きく意味します。一見すると、上記の例はタグの名前空間が上層の人々に所有され、タグが下流にのみ流れるように見えるかもしれませんが、そうではありません。これは、使用パターンが誰が誰のタグに興味を持っているかを決定することを示しているだけです。

ワンショットプルは、コミット履歴が、独自のタグセットを持つ人々のサークル (例: 「カーネルのネットワーキング部分に主に関心がある人々」) から、別のタイプの人々のサークル (例: 「さまざまなサブシステムの改善を統合する人々」) の境界を越えていることを示しています。後者は通常、前者グループ内で内部的に使用される詳細なタグには関心がありません (それが「内部」の意味するところです)。そのため、この場合、タグを自動的に追従しないことが望ましいのです。

ネットワーキングの人々の間では、グループ内部のタグを交換したいと思うかもしれません。しかし、そのワークフローでは、リモート追跡ブランチを持つことで互いの進捗を追跡している可能性が高いです。ここでも、そのようなタグを自動的に追従するヒューリスティックは良いことです。

タグの日付を遡ることについて

別のVCSから変更をインポートし、自分の作業の主要リリースにタグを追加したい場合、タグオブジェクト内に埋め込む日付を指定できると便利です。タグオブジェクト内のそのようなデータは、例えばgitwebインターフェースでのタグの順序に影響します。

将来のタグオブジェクトで使用される日付を設定するには、環境変数 GIT_COMMITTER_DATE を設定します (可能な値については後述を参照。最も一般的な形式は「YYYY-MM-DD HH:MM」です)。

例：

$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1

日付形式

GIT_AUTHOR_DATE および GIT_COMMITTER_DATE 環境変数は、以下の日付形式をサポートしています

Git内部形式

これは <unix-timestamp> <time-zone-offset> で、<unix-timestamp> はUNIXエポックからの秒数です。<time-zone-offset> はUTCからの正または負のオフセットです。例えば、CET (UTCより1時間進んでいる) は +0100 です。

RFC 2822

RFC 2822で記述されている標準的な日付形式です。例えば Thu, 07 Apr 2005 22:13:13 +0200。

ISO 8601

ISO 8601標準で指定された時間と日付です。例えば 2005-04-07T22:13:13。パーサーは T 文字の代わりにスペースも受け入れます。秒の小数部は無視されます。例えば 2005-04-07T22:13:13.019 は 2005-04-07T22:13:13 として扱われます。

注
 さらに、日付部分は以下の形式で受け入れられます: YYYY.MM.DD、MM/DD/YYYY、および DD.MM.YYYY。

ファイル

$GIT_DIR/TAG_EDITMSG

このファイルには、進行中の注釈付きタグのメッセージが含まれています。注釈付きタグを作成する前に git tag がエラーで終了した場合、ユーザーがエディターセッションで提供したタグメッセージはこのファイルで利用可能ですが、次回の git tag の呼び出しによって上書きされる可能性があります。

備考

複数の --contains と --no-contains フィルタを組み合わせる場合、--contains コミットの少なくとも1つを含み、--no-contains コミットのいずれも含まない参照のみが表示されます。

複数の --merged と --no-merged フィルタを組み合わせる場合、--merged コミットの少なくとも1つから到達可能で、--no-merged コミットのいずれからも到達可能でない参照のみが表示されます。

関連項目

git-check-ref-format[1]. git-config[1].

GIT

git[1] スイートの一部

scroll-to-top