Git
英語 ▾ トピック ▾ 最新バージョン ▾ 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` で作成) は「注釈付き」タグと呼ばれます。作成日、タグ付け者の名前と電子メール、タグ付けメッセージ、オプションのGnuPG署名が含まれています。一方、「軽量」タグは単にオブジェクト (通常はコミットオブジェクト) の名前です。

注釈付きタグはリリース用であり、軽量タグはプライベートまたは一時的なオブジェクトラベル用です。このため、オブジェクトに名前を付けるためのいくつかの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>

<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` オプションで指定された色を尊重します。 `<when>` フィールドは、`always`、`never`、または `auto` のいずれかである必要があります ( `<when>` がない場合は、`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]) を使用して、重複したトレーラーを省略するかどうか、トレーラーの実行中に各トレーラーがどこに表示されるか、その他の詳細を定義できます。トレーラーは、`--format="%(trailers)"` プレースホルダーを使用して、`git tag --list` で抽出できます。

-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>

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

<tagname>

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

<commit>
<object>

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

設定

デフォルトでは、sign-with-defaultモード（-s）の *git tag* は、コミッターのID（Your Name <your@email.address> の形式）を使用して鍵を検索します。異なるデフォルトキーを使用したい場合は、リポジトリ設定で次のように指定できます。

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

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

議論

タグの再付与について

間違ったコミットにタグを付けて、タグを付け直したい場合はどうすればよいでしょうか？

何もプッシュしていない場合は、タグを付け直してください。古いタグを置き換えるには "-f" を使用します。これで完了です。

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

  1. 正気な方法。失敗を認め、別の名前を使用するだけです。他の人はすでに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）を使用している可能性が高くなります。通常、相手側のタグが必要です。

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

多くの場合、メーリングリストの「プルしてください」メッセージは、リポジトリ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つは、その分散性です。これは、システムに固有の「アップストリーム」または「ダウンストリーム」がないことを largely意味します。一見すると、上記の例は、タグ名前空間が上位の人々によって所有されており、タグは下向きにのみ流れることを示しているように見えるかもしれませんが、そうではありません。それは、使用パターンによって誰が誰のタグに興味を持っているかが決まることを示しているに過ぎません。

ワンショットプルは、コミット履歴が、独自のタグセット（例：「これは、ネットワーキンググループから2.6.21リリースで一般消費向けに提案された3番目のリリース候補です」）を持っている可能性のある人々のサークル（例：「カーネルのネットワーキング部分に主に興味を持っている人々」）と、別のサークルの人々（例：「さまざまなサブシステムの改善を統合する人々」）との境界を越えていることを示しています。後者は通常、前者のグループ内で内部的に使用される詳細なタグには興味がありません（それが「内部」の意味です）。そのため、この場合はタグを自動的にフォローしないことが望ましいです。

ネットワーキング関係者の間では、グループ内部のタグを交換したい場合もあるかもしれませんが、そのワークフローでは、リモート追跡ブランチを持つことによって互いの進捗状況を追跡している可能性が高くなります。繰り返しますが、そのようなタグを自動的にフォローするヒューリスティックは良いことです。

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

別の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