tag

NAME名

git-tag - Create, list, delete or verify a tag object signed with GPGgit-tag - GPGで署名されたタグオブジェクトを作成、一覧表示、削除、または検証する

SYNOPSIS概要

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>]
	[--[no-]merged [<commit>]] [<pattern>…]
git tag -v [--format=<format>] <tagname>…

DESCRIPTION説明

Add a tag reference in refs/tags/, unless -d/-l/-v is given to delete, list or verify tags.タグの削除、一覧表示、または確認を行うrefs/tags/場合を除いて、タグ参照をに追加し-d/-l/-vます。

Unless -f is given, the named tag must not yet exist.指定しない限り-f、名前付きタグはまだ存在してはいけません。

If one of -a, -s, or -u <keyid> is passed, the command creates a tag object, and requires a tag message. Unless -m <msg> or -F <file> is given, an editor is started for the user to type in the tag message.いずれかが-a、-sまたは-u <keyid>渡され、コマンドは作成されたタグオブジェクトを、タグメッセージを必要とします。ない限り、-m <msg>または-F <file>与えられたユーザーがタグメッセージを入力するために、エディタが起動されます。

If -m <msg> or -F <file> is given and -a, -s, and -u <keyid> are absent, -a is implied.場合-m <msg>または-F <file>与えられたとされ-a、-sおよび-u <keyid>存在しないが、-a暗示されます。

Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created.それ以外の場合は、指定されたオブジェクトを直接指すタグ参照（つまり、軽量タグ）が作成されます。

A GnuPG signed tag object will be created when -s or -u <keyid> is used. When -u <keyid> is not used, the committer identity for the current user is used to find the GnuPG key for signing. The configuration variable gpg.program is used to specify custom GnuPG binary.GnuPG署名付きタグオブジェクトは、使用時-sまたは-u <keyid>使用時に作成されます。-u <keyid>が使用されていない場合は、現在のユーザーのコミッターIDを使用して署名用のGnuPGキーを見つけます。設定変数gpg.programは、カスタムGnuPGバイナリを指定するために使用されます。

Tag objects (created with -a, -s, or -u) are called "annotated" tags; they contain a creation date, the tagger name and e-mail, a tagging message, and an optional GnuPG signature. Whereas a "lightweight" tag is simply a name for an object (usually a commit object).（で作成したタグオブジェクト-a、-sまたは-u「注釈付き」タグと呼ばれています）。それらは作成日、タグ付け者の名前と電子メール、タグ付けメッセージ、そしてオプションのGnuPG署名を含みます。「軽量」タグは単にオブジェクト（通常はコミットオブジェクト）の名前です。

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels. For this reason, some git commands for naming objects (like git describe) will ignore lightweight tags by default.注釈付きタグはリリース用で、軽量タグはプライベートまたは一時的なオブジェクトラベル用です。このため、オブジェクトを命名するためのいくつかのgitコマンド（のようなgit describe）はデフォルトで軽量のタグを無視します。

OPTIONSオプション

-a

--annotate - 注釈

Make an unsigned, annotated tag object無署名の注釈付きタグオブジェクトを作成する

-s

--sign - 符号

Make a GPG-signed tag, using the default e-mail address’s key.デフォルトの電子メールアドレスのキーを使用して、GPG署名付きタグを作成します。

-u <keyid>

--local-user=<keyid> --local-user = <keyid>

Make a GPG-signed tag, using the given key.与えられたキーを使ってGPG署名付きタグを作成します。

-f

--force - 力

Replace an existing tag with the given name (instead of failing)既存のタグを指定された名前に置き換えます（失敗するのではなく）

-d

--delete - 削除

Delete existing tags with the given names.指定された名前の既存のタグを削除します。

-v

--verify - 確認する

Verify the GPG signature of the given tag names.指定されたタグ名のGPG署名を確認してください。

-n<num> -n <番号>

<num> specifies how many lines from the annotation, if any, are printed when using -l. Implies --list.<num>は、-lを使用したときに注釈からの行数（ある場合）を印刷するように指定します。ほのめかし--listます。

The default is not to print any annotation lines. If no number is given to -n, only the first line is printed. If the tag is not annotated, the commit message is displayed instead.デフォルトは注釈行を印刷しません。番号が与えられていない場合は-n、最初の行だけが印刷されます。タグに注釈が付いていない場合は、コミットメッセージが代わりに表示されます。

-l

--list - リスト

List tags. With optional <pattern>..., e.g. git tag --list 'v-*', list only the tags that match the pattern(s).タグを一覧表示します。オプションで<pattern>...、例えばgit tag --list 'v-*'、パターンにマッチするタグだけをリストします。

Running "git tag" without arguments also lists all tags. The pattern is a shell wildcard (i.e., matched using fnmatch(3)). Multiple patterns may be given; if any of them matches, the tag is shown.引数なしで "git tag"を実行しても、すべてのタグが一覧表示されます。パターンはシェルのワイルドカードです（つまり、fnmatch（3）を使用して照合されます）。複数のパターンを指定できます。いずれかが一致すると、タグが表示されます。

This option is implicitly supplied if any other list-like option such as --contains is provided. See the documentation for each of those options for details.このオプションは、他のリストのようなオプション--containsが提供されている場合は暗黙的に提供されます。詳細については、これらの各オプションの資料を参照してください。

--sort=<key> --sort = <key>

Sort based on the key given. Prefix - to sort in descending order of the value. You may use the --sort=<key> option multiple times, in which case the last key becomes the primary key. Also supports "version:refname" or "v:refname" (tag names are treated as versions). The "version:refname" sort order can also be affected by the "versionsort.suffix" configuration variable. The keys supported are the same as those in git for-each-ref. Sort order defaults to the value configured for the tag.sort variable if it exists, or lexicographic order otherwise. See git-config[1].与えられたキーに基づいてソートします。-値の降順でソートするためのプレフィックス。--sort = <key>オプションを複数回使用することができます。その場合、最後のキーが主キーになります。"version：refname"または "v：refname"もサポートします（タグ名はバージョンとして扱われます）。"version：refname"のソート順は "versionsort.suffix"設定変数の影響も受けます。サポートされているキーはと同じgit for-each-refです。ソート順は、tag.sort変数が存在する場合はデフォルトで、それ以外の場合は辞書順に設定された値になります。参照のgit-config設定を[1]。

--color[=<when>] --color [= <when>]

Respect any colors specified in the --format option. The <when> field must be one of always, never, or auto (if <when> is absent, behave as if always was given).--formatオプションで指定された色を尊重してください。<when>フィールドは次のいずれかでなければならないalways、neverまたはauto（場合は<when>存在しない、かのように動作always与えられました）。

-i -私

--ignore-case

Sorting and filtering tags are case insensitive.タグのソートとフィルタリングでは大文字と小文字が区別されません。

--column[=<options>] --column [= <オプション>]

--no-column

Display tag listing in columns. See configuration variable column.tag for option syntax.--column and --no-column without options are equivalent to always and never respectively.タグリストを列で表示します。オプションの構文については構成変数column.tagを参照してください。--columnそして--no-column、オプションなしでは、それぞれalwaysとneverと同等です。

This option is only applicable when listing tags without annotation lines.このオプションは、注釈行なしでタグを一覧表示する場合にのみ適用されます。

--contains [<commit>]

Only list tags which contain the specified commit (HEAD if not specified). Implies --list.指定されたコミットを含むタグのみを一覧表示します（指定されていない場合はHEAD）。ほのめかし--listます。

--no-contains [<commit>]

Only list tags which don’t contain the specified commit (HEAD if not specified). Implies --list.指定されたコミットを含まないタグのみを一覧表示します（指定されていない場合はHEAD）。ほのめかし--listます。

--merged [<commit>]

Only list tags whose commits are reachable from the specified commit (HEAD if not specified), incompatible with --no-merged.指定されたコミット（HEAD指定されていない場合）からそのコミットが到達可能なタグのみを一覧表示します--no-merged。

--no-merged [<commit>]

Only list tags whose commits are not reachable from the specified commit (HEAD if not specified), incompatible with --merged.指定されたコミット（HEAD指定されていない場合）からそのコミットに到達できないタグのみを一覧表示します--merged。

--points-at <object> --points-at <オブジェクト>

Only list tags of the given object (HEAD if not specified). Implies --list.指定されたオブジェクトのタグのみを一覧表示します（指定されていない場合はHEAD）。ほのめかし--listます。

-m <msg>

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

Use the given tag message (instead of prompting). If multiple -m options are given, their values are concatenated as separate paragraphs. Implies -a if none of -a, -s, or -u <keyid> is given.（プロンプトではなく）与えられたタグメッセージを使います。複数の-mオプションが指定されている場合、それらの値は別々の段落として連結されます。意味-aのどれ場合-a、-sまたはが-u <keyid>与えられていません。

-F <file> -F <ファイル>

--file=<file> --file = <ファイル>

Take the tag message from the given file. Use - to read the message from the standard input. Implies -a if none of -a, -s, or -u <keyid> is given.与えられたファイルからタグメッセージを取ります。標準入力からメッセージを読み取るには、-を使用してください。意味-aのどれ場合-a、-sまたはが-u <keyid>与えられていません。

-e

--edit - 編集

The message taken from file with -F and command line with -m are usually used as the tag message unmodified. This option lets you further edit the message taken from these sources.file with -Fおよびcommand line with で取得-mされたメッセージは、通常、変更されていないタグメッセージとして使用されます。このオプションを使用すると、これらのソースから取得したメッセージをさらに編集できます。

--cleanup=<mode> --cleanup = <モード>

This option sets how the tag message is cleaned up. The <mode> can be one of verbatim, whitespace and strip. The strip mode is default. The verbatim mode does not change message at all, whitespace removes just leading/trailing whitespace lines and strip removes both whitespace and commentary.このオプションはタグメッセージがどのようにクリーンアップされるかを設定します。<モード>はのいずれかを指定でき逐語的に、空白とストリップ。ストリップモードがデフォルトです。逐語的なモードがすべてでメッセージを変更しない、空白はちょうど一流/末尾の空白行と削除ストリップを空白と解説の両方を削除します。

--create-reflog

Create a reflog for the tag. To globally enable reflogs for tags, see core.logAllRefUpdates in git-config[1]. The negated form --no-create-reflog only overrides an earlier --create-reflog, but currently does not negate the setting of core.logAllRefUpdates.タグのreflogを作成してください。タグのreflogをグローバルに有効にするにはcore.logAllRefUpdates、git-config [1]を参照してください。否定形式--no-create-reflogは、以前の形式をオーバーライドするだけですが、--create-reflog現在の設定を否定するものではありませんcore.logAllRefUpdates。

--format=<format> --format = <フォーマット>

A string that interpolates %(fieldname) from a tag ref being shown and the object it points at. The format is the same as that of git-for-each-ref[1]. When unspecified, defaults to %(refname:strip=2).%(fieldname)表示されているタグrefとそれが指すオブジェクトから補間する文字列。フォーマットはgit-for-each-ref [1]と同じです。指定しない場合、デフォルトはになり%(refname:strip=2)ます。

<tagname> <タグ名>

The name of the tag to create, delete, or describe. The new tag name must pass all checks defined by git-check-ref-format[1]. Some of these checks may restrict the characters allowed in a tag name.作成、削除、または説明するタグの名前。新しいタグ名はgit-check-ref-format [1]で定義されているすべてのチェックに合格する必要があります。これらのチェックの中には、タグ名に使用できる文字を制限するものがあります。

<commit> <コミット>

<object> <オブジェクト>

The object that the new tag will refer to, usually a commit. Defaults to HEAD.新しいタグが参照するオブジェクト。通常はコミットです。デフォルトはHEADです。

CONFIGURATION設定

By default, git tag in sign-with-default mode (-s) will use your committer identity (of the form Your Name <your@email.address>) to find a key. If you want to use a different default key, you can specify it in the repository configuration as follows:デフォルトでは、sign-with-defaultモード（-s）のgit tagはYour Name <your@email.address>キーを見つけるために（フォームの）あなたのコミッターIDを使用します。別のデフォルトキーを使用する場合は、次のようにリポジトリ設定でそれを指定できます。

[user]
    signingKey = <gpg-keyid>

pager.tag is only respected when listing tags, i.e., when -l is used or implied. The default is to use a pager. See git-config[1].pager.tagタグを一覧表示するとき、つまり、-lが使用されているか暗黙的に指定されている場合にのみ使用されます。デフォルトではポケットベルを使用します。参照のgit-config設定を[1]。

DISCUSSION討論

On Re-tagging再タグ付けについて

What should you do when you tag a wrong commit and you would want to re-tag?間違ったコミットにタグを付けて、再度タグを付けたい場合はどうしますか。

If you never pushed anything out, just re-tag it. Use "-f" to replace the old one. And you’re done.何も押し出さなかった場合は、それにタグを付け直すだけです。古いものを置き換えるには "-f"を使用してください。そして、これで終わりです。

But if you have pushed things out (or others could just read your repository directly), then others will have already seen the old tag. In that case you can do one of two things:しかし、あなたが物事を押し出した場合（あるいは他の人が直接あなたのリポジトリを読むことができる場合）、他の人はすでに古いタグを見たことがあるでしょう。その場合は、次の2つのうちのいずれかを実行できます。

The sane thing. Just admit you screwed up, and use a different name. Others have already seen one tag-name, and if you keep the same name, you may be in the situation that two people both have "version X", but they actually have different "X"'s. So just call it "X.1" and be done with it.正直なこと。あなたが失敗したことを認めて、違う名前を使ってください。他の人はすでに1つのtag-nameを見ています、そしてあなたが同じ名前を保持するならば、あなたは2人の人が両方とも "バージョンX"を持っているが実際には異なる "X"を持っている状況にあるかもしれません。それで、それを単に "X.1"と呼び、それを使ってください。
The insane thing. You really want to call the new version "X" too, even though others have already seen the old one. So just use git tag -f again, as if you hadn’t already published the old one.めちゃくちゃなこと。他の人がすでに古いバージョンを見たことがあるとしても、あなたは本当に新しいバージョンを "X"と呼ぶことを望みます。ですから、git tag -fをもう一度使ってください。あたかもまだ古いものを公開していないかのように。

However, Git does not (and it should not) change tags behind users back. So if somebody already got the old tag, doing a git pull on your tree shouldn’t just make them overwrite the old one.しかし、Gitはユーザーの背後にあるタグを元に戻すことはありません（そしてそうすべきではありません）。ですから、誰かがすでに古いタグを手に入れているのなら、ツリーをgit pullしても古いタグを上書きしてはいけません。

If somebody got a release tag from you, you cannot just change the tag for them by updating your own one. This is a big security issue, in that people MUST be able to trust their tag-names. If you really want to do the insane thing, you need to just fess up to it, and tell people that you messed up. You can do that by making a very public announcement saying:誰かがあなたからリリースタグを取得した場合、あなたはあなた自身のものを更新することによってそれらのタグを変更することはできません。人々は自分のタグ名を信頼できなければならないという点で、これは大きなセキュリティ問題です。あなたが本当に非常識なことをしたいのであれば、あなたはただそれに戸惑い、あなたがめちゃくちゃであることを人々に伝える必要があります。あなたが言って非常に一般の発表をすることによってそれをすることができます：

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.

Does this seem a bit complicated? It should be. There is no way that it would be correct to just "fix" it automatically. People need to know that their tags might have been changed.これは少し複雑に見えますか？あるはずです。自動的に「修正」するだけでは正しい方法はありません。人々は自分のタグが変更された可能性があることを知る必要があります。

On Automatic following自動追従について

If you are following somebody else’s tree, you are most likely using remote-tracking branches (eg. refs/remotes/origin/master). You usually want the tags from the other end.もしあなたが他の誰かの木をフォローしているなら、あなたはたぶんリモートトラッキングブランチ（例えばrefs/remotes/origin/master）を使っています。あなたは通常相手側からのタグが欲しいです。

On the other hand, if you are fetching because you would want a one-shot merge from somebody else, you typically do not want to get tags from there. This happens more often for people near the toplevel but not limited to them. Mere mortals when pulling from each other do not necessarily want to automatically get private anchor point tags from the other person.一方、他人からのワンショットマージが必要なためにフェッチしている場合は、通常そこからタグを取得することは望ましくありません。これはトップレベルの近くの人々のためにより頻繁に起こるが、彼らに限定されない。お互いを引っ張ってくるときに単なる人間が必ずしも他の人からプライベートアンカーポイントタグを自動的に取得したくない場合があります。

Often, "please pull" messages on the mailing list just provide two pieces of information: a repo URL and a branch name; this is designed to be easily cut&pasted at the end of a git fetch command line:多くの場合、メーリングリストに "プルしてください"というメッセージは2つの情報を提供するだけです：レポURLとブランチ名。これはgit fetchコマンドラインの最後に簡単にカットアンドペーストできるように設計されています。

Linus, please pull from
	git://git..../proj.git master
to get the following updates...

becomes:になる：

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

In such a case, you do not want to automatically follow the other person’s tags.そのような場合、あなたは自動的に他の人のタグに従うことを望みません。

One important aspect of Git is its distributed nature, which largely means there is no inherent "upstream" or "downstream" in the system. On the face of it, the above example might seem to indicate that the tag namespace is owned by the upper echelon of people and that tags only flow downwards, but that is not the case. It only shows that the usage pattern determines who are interested in whose tags.Gitの1つの重要な側面はその分散された性質です。これは、システムに固有の「上流」または「下流」がないことを主に意味します。それにもかかわらず、上記の例は、タグの名前空間が人々の上層部によって所有されており、タグは下方向にのみ流れることを示しているように思われるかもしれませんが、そうではありません。使い方のパターンによって、だれがどのタグに興味を持っているかが決まるだけです。

A one-shot pull is a sign that a commit history is now crossing the boundary between one circle of people (e.g. "people who are primarily interested in the networking part of the kernel") who may have their own set of tags (e.g. "this is the third release candidate from the networking group to be proposed for general consumption with 2.6.21 release") to another circle of people (e.g. "people who integrate various subsystem improvements"). The latter are usually not interested in the detailed tags used internally in the former group (that is what "internal" means). That is why it is desirable not to follow tags automatically in this case.ワンショットプルとは、コミット履歴が、独自のタグセットを持つ可能性がある人々の1つのサークル（たとえば、「カーネルのネットワーク部分に主に関心を持つ人々」など）の境界を越えていることを示すサインです。これは、ネットワーキンググループから2.6.21リリースで一般消費向けに提案される3番目のリリース候補です（ "さまざまなサブシステムの改良を統合した人々"など）。後者は通常、前者のグループの内部で使用されている詳細なタグには関心がありません（それが「内部」の意味です）。この場合、タグを自動的にたどらないことが望ましいのはそのためです。

It may well be that among networking people, they may want to exchange the tags internal to their group, but in that workflow they are most likely tracking each other’s progress by having remote-tracking branches. Again, the heuristic to automatically follow such tags is a good thing.ネットワーキング関係の人々の間では、タグをグループの内部で交換したい場合があるかもしれませんが、そのワークフローでは、リモートトラッキングブランチを使用して互いの進捗状況をトラッキングしている可能性があります。繰り返しますが、そのようなタグに自動的に従うというヒューリスティックは良いことです。

On Backdating Tagsバックデートタグについて

If you have imported some changes from another VCS and would like to add tags for major releases of your work, it is useful to be able to specify the date to embed inside of the tag object; such data in the tag object affects, for example, the ordering of tags in the gitweb interface.他のVCSからいくつかの変更をインポートしていて、あなたの作品のメジャーリリースのためにタグを追加したいのであれば、タグオブジェクトの中に埋め込む日付を指定できると便利です。タグオブジェクト内のこのようなデータは、たとえばgitwebインターフェイス内のタグの順序に影響します。

To set the date used in future tag objects, set the environment variable GIT_COMMITTER_DATE (see the later discussion of possible values; the most common form is "YYYY-MM-DD HH:MM").将来のタグオブジェクトで使用される日付を設定するには、環境変数GIT_COMMITTER_DATEを設定します（可能な値については後述の説明を参照してください。最も一般的な形式は "YYYY-MM-DD HH：MM"です）。

For example:例えば：

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

DATE FORMATS日付フォーマット

The GIT_AUTHOR_DATE, GIT_COMMITTER_DATE environment variables support the following date formats:GIT_AUTHOR_DATE、GIT_COMMITTER_DATE環境変数は次の日付形式をサポートしています。

Git internal format Gitの内部フォーマット

It is <unix timestamp> <time zone offset>, where <unix timestamp> is the number of seconds since the UNIX epoch. <time zone offset> is a positive or negative offset from UTC. For example CET (which is 1 hour ahead of UTC) is +0100.これは、ある<unix timestamp> <time zone offset>場合には、<unix timestamp>UNIXエポックからの秒数です。<time zone offset>UTCからの正または負のオフセットです。例えばCET（これはUTCより1時間進んでいます）です+0100。

RFC 2822

The standard email format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200.たとえば、RFC 2822で説明されている標準の電子メール形式Thu, 07 Apr 2005 22:13:13 +0200。

ISO 8601

Time and date specified by the ISO 8601 standard, for example 2005-04-07T22:13:13. The parser accepts a space instead of the T character as well.たとえば、ISO 8601規格で指定されている日時2005-04-07T22:13:13。パーサーはT文字の代わりにスペースも受け入れます。

Note	In addition, the date part is accepted in the following formats: `YYYY.MM.DD`, `MM/DD/YYYY` and `DD.MM.YYYY`. さらに、日付部分は次の形式で受け入れられます。`YYYY.MM.DD`、`MM/DD/YYYY`および`DD.MM.YYYY`。