git-tag - クラウドでオンライン

プログラム：

NAME

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

SYNOPSIS

git タグ [-a | -s | -u ] [-f] [-m | -F 】
[ | 】
git タグ -d ...
git タグ [-n[ ]] -l [--を含む] [--ポイント- 】
[--列[= ] | --no-column] [--create-reflog] [--sort= 】
[--format= ] [--[no-]マージされました [ ]] [ ...]
git タグ -v ...

DESCRIPTION

削除、リスト、または検証のために -d/-l/-v が指定されていない限り、タグ参照を refs/tags/ に追加します。
タグ。

-f を指定しない限り、名前付きタグはまだ存在してはいけません。

-a、-s、または -u のいずれかの場合が渡されると、コマンドは タグ 反対し、要求する
タグメッセージ。 -m でない場合または -F が与えられると、ユーザーが次のことを行うためにエディタが起動されます。
タグメッセージを入力します。

-mの場合または -F -a、-s、および -u が指定されているが存在しない場合、-a が暗黙的に指定されます。

それ以外の場合は、コミット オブジェクトの SHA-1 オブジェクト名のタグ参照のみが作成されます。
(つまり、軽量タグ)。

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

タグ オブジェクト (-a、-s、または -u で作成) は「注釈付き」タグと呼ばれます。 それらには、
作成日、タガー名と電子メール、タグ付けメッセージ、およびオプションの GnuPG
サイン。 一方、「軽量」タグは単にオブジェクト (通常はコミット) の名前です。
オブジェクト)。

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

OPTIONS

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

-s、--sign
デフォルトの電子メール アドレスのキーを使用して、GPG 署名付きタグを作成します。

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

-f、-force
既存のタグを指定された名前で置き換えます (失敗するのではなく)

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

-v、--verify
指定されたタグ名の GPG 署名を確認します。

-n
-l を使用した場合に、アノテーション (存在する場合) から何行出力するかを指定します。
デフォルトでは、注釈行は印刷されません。 -n に数値が指定されていない場合は、
最初の行が印刷されます。 タグに注釈が付けられていない場合、コミット メッセージは次のようになります。
代わりに表示されます。

-l 、 --リスト
指定されたパターンに一致する名前を持つタグをリストします (パターンが指定されていない場合はすべて)。
引数なしで「git tag」を実行すると、すべてのタグもリストされます。 模様は貝殻です
ワイルドカード (つまり、次を使用して一致) fnmatch(3))。 複数のパターンを指定することもできます。 いずれかの場合
それらが一致すると、タグが表示されます。

--sort=
指定されたキーに基づいて並べ替えます。 プレフィックス - 値の降順に並べ替えます。 あなた
--sort= を使用することもできますオプションを複数回繰り返した場合、最後のキーが
主キー。 「version:refname」または「v:refname」もサポートします（タグ名は次のように扱われます）
バージョン）。 「version:refname」のソート順序は、
「versionsort.prereleaseSuffix」構成変数。 サポートされているキーは同じです
git for-each-ref のものと同様です。 ソート順序のデフォルトは、
タグの並べ替え 変数が存在する場合は変数、存在しない場合は辞書編集順です。 見る git-configとします。

-列[= ]、-no-column
タグのリストを列に表示します。 オプションについては構成変数 column.tag を参照してください。
syntax.--column および --no-column オプションなしの場合は、次と同等です。 常に 　 決して
。

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

-- を含む [ ]
指定されたコミット (指定されていない場合は HEAD) を含むタグのみをリストします。

--ポイントポイント
指定されたオブジェクトのタグのみをリストします。

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

-F 、 --file=
指定されたファイルからタグ メッセージを取得します。 使用 - 標準からのメッセージを読むには
入力。 -a、-s、または -u のいずれでもない場合は、-a を暗黙的に指定します。 が与えられる。

--クリーンアップ=
このオプションは、タグ メッセージをクリーンアップする方法を設定します。 の のXNUMXつになることができます 逐語的,
空白 　 ストリップを選択します。 ストリップ モードはデフォルトです。 の 逐語的 モードは変わらない
まったくメッセージ、 空白 先頭/末尾の空白行のみを削除し、 ストリップ
空白とコメントの両方を削除します。

--create-reflog
タグの reflog を作成します。


作成、削除、または説明するタグの名前。 新しいタグ名はすべてを渡す必要があります
によって定義されたチェック git-check-ref-format(1)。 これらのチェックの一部では、
タグ名に使用できる文字。

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


ref が指すオブジェクトから %(fieldname) を補間する文字列
示されています。 フォーマットは以下のものと同じです 各参照の git(1)。 指定しない場合は、
デフォルトは %(refname:strip=2) です。

--[no-]マージ済み [ 】
ヒントが到達可能なタグのみをリストするか、次の場合には到達できないタグのみをリストします。 --マージなし から使用されます
指定されたコミット (HEAD 指定されていない場合）。

CONFIGURATION

デフォルトでは、 git タグ デフォルトで署名モード (-s) では、コミッター ID (の
あなたの名前のフォーム[メール保護]>) キーを見つけます。 別のものを使用したい場合は、
デフォルトのキーは、次のようにリポジトリ設定で指定できます。

[ユーザー]
署名キー =

考察

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

何もプッシュしたことがない場合は、タグを付け直すだけです。 古いものを置き換えるには「-f」を使用します。 そして
もう終わりです。

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

1. 正気のこと。 失敗したことを認めて、別の名前を使用してください。 他の人は持っています
すでに XNUMX つのタグ名を参照しており、同じ名前を使用すると、次のような状況になる可能性があります。
XNUMX 人は両方とも「バージョン X」を持っていますが、実際には 今とは異なる 「X」です。 これだけ
それを「X.1」と呼んで、それで終わりです。

2. 非常識なこと。 本当は新しいバージョンも「X」と呼びたいのですが、 さらに しかし others
古いものはすでに見ました。 だから、ただ使ってください git タグ -f もう一度、まるでまだそうでなかったかのように
古いものを公開しました。

ただし、Git では、 ユーザーの背後でタグを変更する (そして、変更すべきではない)。それで誰かが
すでに古いタグを取得しているため、 git プル あなたのツリー上で単に上書きさせるべきではありません
古いもの。

誰かがあなたからリリースタグを受け取った場合、単にその人のタグを変更することはできません。
自分のものを更新します。 これは、人々が信頼できなければならないという点で、セキュリティ上の大きな問題です。
彼らのタグ名。 本当に非常識なことをしたいのなら、ただ大騒ぎする必要がある
そして、あなたがめちゃくちゃだったことを人々に伝えてください。 非常に公開することでそれが可能になります
というアナウンス：

OK、失敗してしまい、X というタグが付いた以前のバージョンをプッシュしてしまいました。
それから何かを修正し、*修正された* ツリーを再度 X としてタグ付けし直しました。

タグが間違っていて新しいタグが必要な場合は削除してください
次のようにして、古いものを取得し、新しいものを取得します。

git タグ -d X
git fetch オリジンタグ X

更新されたタグを取得します。

次のようにして、どのタグを持っているかをテストできます

git rev-parse X

新しいバージョンを使用している場合は、0123456789abcdef.. が返されるはずです。

ご迷惑をおかけして申し訳ありません。

これは少し複雑に思えますか? それ すべき なれ。 それが正しいわけがない
自動的に「修正」するだけです。 自分のタグが不正に使用されている可能性があることを人々は知る必要があります
変更されました。

On オートマチック フォロー中
他の人のツリーをフォローしている場合は、リモート追跡を使用している可能性が高くなります。
ブランチ (従来のレイアウトでは refs/heads/origin、またはレイアウトでは refs/remotes/origin/master)
セパレートリモートレイアウト)。 通常は、相手側からのタグが必要になります。

一方、ワンショットマージが必要なためにフェッチしている場合は、
通常、そこからタグを取得することは望ましくありません。これはより頻繁に起こります
トップレベルに近い人々が対象ですが、これに限定されません。 それぞれから引っ張るときは単なる定命の者
他のユーザーは、必ずしもプライベート アンカー ポイント タグを自動的に取得する必要はありません。
他の人。

多くの場合、メーリング リストの「プルしてください」メッセージは、次の XNUMX つの情報を提供するだけです。
リポジトリ URL とブランチ名。 これは、ファイルの最後に簡単にカットアンドペーストできるように設計されています。 git
フェッチ コマンドライン：

ライナス、そこから引っ張ってください

git://git..../proj.git マスター

次のアップデートを入手するには...

になります：

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

そんなとき、相手のタグを自動フォローしたくないですよね。

Git の重要な側面の XNUMX つは、その分散型の性質です。これは主に、
システムに固有の「上流」または「下流」。 一見すると、上の例は
タグの名前空間が上層部の人々によって所有されていることを示しているように見えるかもしれません。
タグは下方向にのみ流れると考えられていますが、そうではありません。 使用法を示すだけです
パターンは、誰が誰のタグに関心があるかを決定します。

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

ネットワーキングに携わる人々の間では、社内でタグを交換したいと考える人もいるかもしれません。
しかし、そのワークフローでは、おそらくお互いの進捗状況を追跡しているでしょう。
リモート追跡ブランチを持つことによって。 繰り返しになりますが、このようなタグを自動的に追跡するヒューリスティック
良いことです。

On バックデーティング タグ
別の VCS からいくつかの変更をインポートし、主要なタグを追加したい場合
作品のリリースの場合、ファイル内に埋め込む日付を指定できると便利です。
タグオブジェクト; タグ オブジェクト内のこのようなデータは、たとえば、タグ オブジェクト内のタグの順序に影響します。
gitweb インターフェイス。

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

具体的な例を挙げますと、以下の通りです。

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

DATE 書式

GIT_AUTHOR_DATE、GIT_COMMITTER_DATE 環境変数は次の日付をサポートします。
フォーマット：

Gitの内部形式
それは、 どこの数です
UNIX エポックからの秒数。 正または負のオフセットです
UTCから。 たとえば、CET (協定世界時より 2 時間進んでいます) は +0200 です。

RFC 2822
RFC 2822 で説明されている標準電子メール形式 (例: Thu, 07 Apr 2005)
22:13:13 +0200。

ISO 8601
ISO 8601 標準で指定された日時 (例: 2005-04-07T22:13:13)。 の
パーサーは、T 文字の代わりにスペースも受け入れます。

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

onworks.net サービスを使用してオンラインで git-tag を使用する