コマンド名
「git-tag」：GPGで署名されたタグオブジェクトを作成、一覧表示、削除、または検証します
概要
git tag [-a | -s | -u <keyid>] [-f] [-m <msg> | -F <file>] [-e]
<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 <keyid> のいずれかがパスされると、コマンドは「tag」オブジェクトを作成し、タグメッセージを要求します。-m <msg>もしくは-F <file> が指定されていない限り、ユーザーがタグメッセージを入力するためのエディターが起動します。
m <msg>または-F <file> が指定され、-a、-s、-u <keyid> がない場合、-aが指定されます。
それ以外の場合、指定されたオブジェクトを直接指すタグ参照（つまり、軽量タグ）が作成されます。
-s または-u <keyid>を使用すると、GnuPG署名付きタグオブジェクトが作成されます。-u <keyid>が使用されていない場合、現在のユーザーのコミッターIDを使用して、署名用のGnuPGキーが検索されます。構成変数gpg.programはカスタムGnuPGバイナリを指定するために使用されます。
タグオブジェクト（-a、-s、もしくは-uで作成）は「注釈付き」タグと呼ばれています。これらには作成日、タガー名と電子メール、タグ付けメッセージ、およびオプションのGnuPG署名が含まれています。一方、「軽量」タグは単にオブジェクト（通常はコミットオブジェクト）の名前です。
注釈付きタグはリリース用であり、軽量タグはプライベートまたは一時的なオブジェクトラベル用です。このためオブジェクトに名前を付けるための一部のgitコマンド（git describeなど）はデフォルトで軽量タグを無視します。
オプション
-a
--annotate
--annotate
署名されていない注釈付きのタグオブジェクトを作成します
-s
--sign
--sign
デフォルトの電子メールアドレスのキーを使用して、GPG署名付きタグを作成します。タグGPG署名のデフォルトの動作はtag.gpgSign構成変数が存在する場合はそれによってコントロールされ、存在しない場合は無効になります。git-config[1]を参照してください。
--no-sign
すべてのタグに強制的に署名するように設定されているtag.gpgSign構成変数を上書きします。
-u <keyid>
--local-user=<keyid>
--local-user=<keyid>
指定されたキーを使用して、GPG署名付きタグを作成します。
-f
--force
--force
既存のタグを（失敗するのではなく）指定された名前に置き換えます。
-d
--delete
--delete
指定された名前の既存のタグを削除します。
-v
--verify
--verify
指定されたタグ名のGPG署名を確認します。
-n<num>
<num>は「-l」を使用する時、注釈から何ラインプリントされるかを指定します。--listを意味します。
デフォルトでは注釈ラインはプリントされません。-nに番号が指定されていない場合、最初のラインのみが出力されます。タグに注釈が付けられていない場合、代わりにコミットメッセージが表示されます。
-l
--list
--list
タグを一覧表示します。オプションの<pattern>...を使用します。例えばgit tag --list 'v-*'などパターンに一致するタグのみを一覧表示します。
引数なしで「gittag」を実行すると、すべてのタグも一覧表示されます。パターンはシェルワイルドカードです（つまり、「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
--ignore-case
タグの並べ替えとフィルタリングでは大文字と小文字は区別されません。
--column[=<options>]
--no-column
--no-column
タグリストを列に表示します。オプションの構文については構成変数「column.tag」を参照してください。--column および--no-column オプションなしはそれぞれ「always」および「never」と同等です。
このオプションは注釈行のないタグをリストする場合にのみ適用できます。
--contains [<commit>]
指定されたコミットを含むタグのみを一覧表示します（指定されていない場合はヘッドとなります）。--listを意味します。
--no-contains [<commit>]
指定されたコミットを含まないタグのみを一覧表示します（指定されていない場合はヘッドとなります）。--listを意味します。
--merged [<commit>]
指定されたコミットからコミットに到達できるタグのみを一覧表示します（指定されていない場合はヘッドとなります）。
--no-merged [<commit>]
指定されたコミットからコミットに到達できないタグのみを一覧表示します（指定されていない場合はHEADとなります）。
--points-at <object>
指定されたオブジェクトのタグのみを一覧表示します（指定されていない場合はHEADとなります）。--listを意味します。
-m <msg>
--message=<msg>
--message=<msg>
（プロンプトの代わりに）指定されたタグメッセージを使用します。複数の-mオプションが指定されている場合、それらの値は個別の段落として連結されます。-a、-s、または-u <keyid>のいずれも指定されていない場合、-aを意味します。
-F <file>
--file=<file>
--file=<file>
指定されたファイルからタグメッセージを取得します。「-」を使用し、標準入力からメッセージを読み取ります。-a、-s、または-u <keyid>のいずれも指定されていない場合、-aを意味します。
-e
--edit
--edit
-Fを使用してファイルから取得したメッセージと-m を使用してコマンドラインを使用したメッセージは通常、変更されていないタグメッセージとして使用されます。このオプションを使用すると、これらのソースから取得したメッセージをさらに編集できます。
--cleanup=<mode>
このオプションはタグメッセージのクリーンアップ方法を設定します。<mode>は逐語的、空白、ストリップのいずれかになります。ストリップモードがデフォルトとなっています。逐語的モードはメッセージをまったく変更せず、空白は先頭/末尾の空白行のみを削除し、ストリップは空白と解説の両方を削除します。
--create-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>
<object>
新しいタグが参照するオブジェクトであり、通常はコミットです。デフォルトはHEADです。
構成
デフォルトでは「sign-with-default」モード（-s）の「git tag」はコミッターID（Your Name <your@email.address>の形式）を使用してキーを検索します。別のデフォルトキーを使用する場合、リポジトリ構成で次のように指定できます。
[user] signingKey = <gpg-keyid>
pager.tagはタグを一覧表示する場合、つまり-lが使用または暗示されている場合にのみ優先されます。デフォルトではページャーを使用します。git-config[1]を参照してください。
議論
再タグ付けについて
間違ったコミットにタグを付け、再度タグを付けたい場合はどうすればよいでしょうか？
何もプッシュしたことがない場合、タグを付け直してください。「-f」を使用して古いものを置き換えます。これで完了です。
しかし、あなたがプッシュした場合（または他の人があなたのリポジトリを直接読み取ることができた場合）、他の人はすでに古いタグを見ているでしょう。その場合、次の2つのいずれかを実行できます。
- 通常のことです。失敗したことを認めて、別の名前を使用してください。他の人はすでに1つのタグ名を見たことがあり、同じ名前を保持している場合、2人が両方とも「バージョンX」を持っている状況にあるかもしれませんが、実際には異なる「X」を持っています。だからそれを「X.1」と呼んで、それで完了です。
- 通常ではない方法についてです。他の人がすでに古いバージョンを見たとしても、あなたは新しいバージョンを「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つの情報を提供するだけです。これは「gitfetch」コマンドラインの最後で簡単にカットアンドペーストできるように設計されています。
Linus, please pull from git://git..../proj.git master to get the following updates...
次のようになります。
$ git pull git://git..../proj.git master
このような場合、他の人のタグを自動的にフォローしたくありません。
Gitの重要な側面の1つはその分散性です。これは主にシステムに固有の「上流」または「下流」がないことを意味します。一見すると上記の例はタグの名前空間が人々の上層部によって所有されており、タグが下向きにのみ流れることを示しているように見えるかもしれませんが、そうではありません。使用パターンによって、誰が誰のタグに関心があるかが決まることだけが示されています。
ワンショットプルはコミット履歴が独自のタグセット（例えば、「カーネルのネットワーク部分に主に関心のある人」）の1つのサークルであるネットワーキンググループから2.6.21リリースで一般に提案される3番目のリリース候補となっています」）から別の人々のサークル（例えば、「様々なサブシステムの改善を統合する人」）へとバウンダリーを越えていることを示しています。この後者は通常、前者のグループで内部的に使用される詳細なタグには関係がありません（これが「内部」の意味です）。そのため、この場合、タグを自動的に追跡しないことが望ましいです。
ネットワーキングの人々の間ではグループ内でタグを交換したいと思うかもしれませんが、そのワークフローではリモート追跡ブランチを使用して互いの進捗状況を追跡している可能性があります。 繰り返しますが、そのようなタグを自動的に追跡するヒューリスティックは良いことです。
バックデートタグについて
別のVCSからいくつかの変更をインポートし、ワークのメジャーリリースのタグを追加したい場合はタグオブジェクト内に埋め込む日付を指定できると便利です。タグオブジェクト内のこのようなデータは例えば「gitweb」インターフェイスでのタグの順序に影響します。
将来のタグオブジェクトで使用される日付を設定するには環境変数「GIT_COMMITTER_DATE」を設定します（可能な値については後の説明を参照してください。最も一般的な形式は「YYYY-MM-DDHH：MM」です）。
例えば次のような例です。
$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
日付形式
GIT_AUTHOR_DATE, GIT_COMMITTER_DATE環境変数は次の日付形式をサポートしています。
Git internal format
これは<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の形式で受け入れられます。
注記
複数の—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]パッケージソフトの一部