日本語 ▾ トピック ▾ 最新バージョン ▾ 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>

<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

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

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

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

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

--contains [<commit>]

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

--no-contains [<commit>]

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

--merged [<commit>]

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

--no-merged [<commit>]

指定されたコミット (HEAD が指定されない場合は 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つを行うことができます。

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

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

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

タグの遡及について

他の 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 フィルターを組み合わせる場合、少なくとも1つの --contains コミットを含み、かつ --no-contains コミットを一切含まない参照のみが表示されます。

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

関連項目

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

GIT

git[1]スイートの一部

scroll-to-top