# git-tag > 原文： [https://git-scm.com/docs/git-tag](https://git-scm.com/docs/git-tag) ## 名稱 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>] [--[no-]merged [<commit>]] [<pattern>…?] git tag -v [--format=<format>] <tagname>…? ``` ## 描述 在`refs/tags/`中添加標記引用，除非`-d/-l/-v`用于刪除，列出或驗證標記。 除非給出`-f`，否則指定的標記必須不存在。 如果傳遞`-a`，`-s`或`-u &lt;keyid&gt;`之一，該命令將創建_標簽_對象，并需要標記消息。除非給出`-m &lt;msg&gt;`或`-F &lt;file&gt;`，否則將啟動編輯器以供用戶鍵入標記消息。 如果給出`-m &lt;msg&gt;`或`-F &lt;file&gt;`并且`-a`，`-s`和`-u &lt;keyid&gt;`不存在，則暗示`-a`。 否則，創建直接指向給定對象（即，輕量標簽）的標簽引用。 使用`-s`或`-u &lt;keyid&gt;`時，將創建GnuPG簽名標記對象。如果未使用`-u &lt;keyid&gt;`，則使用當前用戶的提交者標識來查找用于簽名的GnuPG密鑰。配置變量`gpg.program`用于指定自定義GnuPG二進制文件。 標記對象（使用`-a`，`-s`或`-u`創建）稱為“帶注釋”標記;它們包含創建日期，標記器名稱和電子郵件，標記消息以及可選的GnuPG簽名。而“輕量級”標簽只是對象的名稱（通常是提交對象）。 帶注釋的標簽用于發布，而輕量級標簽用于私有或臨時對象標簽。因此，一些用于命名對象的git命令（如`git describe`）將默認忽略輕量級標記。 ## OPTIONS ``` -a ``` ``` --annotate ``` 創建一個未簽名的帶注釋的標記對象 ``` -s ``` ``` --sign ``` 使用默認電子郵件地址密鑰創建GPG簽名標記。 ``` -u <keyid> ``` ``` --local-user=<keyid> ``` 使用給定密鑰創建GPG簽名標記。 ``` -f ``` ``` --force ``` 用給定名稱替換現有標記（而不是失敗） ``` -d ``` ``` --delete ``` 刪除具有給定名稱的現有標簽。 ``` -v ``` ``` --verify ``` 驗證給定標記名稱的GPG簽名。 ``` -n<num> ``` &lt; NUM&gt;指定在使用-l時打印注釋的行數（如果有）。意味著`--list`。 默認情況下不打印任何注釋行。如果`-n`沒有給出編號，則只打印第一行。如果標記未注釋，則顯示提交消息。 ``` -l ``` ``` --list ``` 列出標簽。使用可選的`&lt;pattern&gt;...`，例如`git tag --list 'v-*'`，僅列出與模式匹配的標記。 不帶參數運行“git tag”也會列出所有標簽。該模式是shell通配符（即，使用fnmatch（3）匹配）。可以給出多種模式;如果它們中的任何一個匹配，則顯示標記。 如果提供了任何其他類似列表的選項（如`--contains`），則會隱式提供此選項。有關詳細信息，請參閱每個選項的文檔。 ``` --sort=<key> ``` 根據給定的密鑰排序。前綴`-`按值的降序排序。您可以使用--sort =&lt; key&gt;選項多次，在這種情況下，最后一個鍵成為主鍵。還支持“version：refname”或“v：refname”（標記名稱被視為版本）。 “version：refname”排序順序也可能受“versionsort.suffix”配置變量的影響。支持的鍵與`git for-each-ref`中的鍵相同。排序順序默認為`tag.sort`變量（如果存在）配置的值，否則為字典順序。見 [git-config [1]](https://git-scm.com/docs/git-config) 。 ``` --color[=<when>] ``` 尊重`--format`選項中指定的任何顏色。 `&lt;when&gt;`字段必須是`always`，`never`或`auto`之一（如果`&lt;when&gt;`不存在，則表現得好像`always`一樣）。 ``` -i ``` ``` --ignore-case ``` 排序和過濾標簽不區分大小寫。 ``` --column[=<options>] ``` ``` --no-column ``` 在列中顯示標記列表。有關選項語法，請參閱配置變量column.tag。沒有選項的`--column`和`--no-column`分別相當于和_永遠不會_。 此選項僅在列出沒有注釋行的標簽時適用。 ``` --contains [<commit>] ``` 僅列出包含指定提交的標記（如果未指定，則為HEAD）。意味著`--list`。 ``` --no-contains [<commit>] ``` 僅列出不包含指定提交的標記（如果未指定，則為HEAD）。意味著`--list`。 ``` --merged [<commit>] ``` 僅列出其提交可從指定提交到達的標記（如果未指定，則為`HEAD`），與`--no-merged`不兼容。 ``` --no-merged [<commit>] ``` 僅列出其提交無法從指定提交到達的標記（如果未指定，則為`HEAD`），與`--merged`不兼容。 ``` --points-at <object> ``` 僅列出給定對象的標簽（如果未指定，則為HEAD）。意味著`--list`。 ``` -m <msg> ``` ``` --message=<msg> ``` 使用給定的標記消息（而不是提示）。如果給出了多個`-m`選項，則它們的值將作為單獨的段落連接在一起。如果沒有給出`-a`，`-s`或`-u &lt;keyid&gt;`，則表示`-a`。 ``` -F <file> ``` ``` --file=<file> ``` 從給定文件中獲取標記消息。使用 _-_ 從標準輸入讀取信息。如果沒有給出`-a`，`-s`或`-u &lt;keyid&gt;`，則表示`-a`。 ``` -e ``` ``` --edit ``` 從帶有`-F`的文件和帶有`-m`的命令行獲取的消息通常用作未修改的標記消息。此選項允許您進一步編輯從這些來源獲取的消息。 ``` --cleanup=<mode> ``` 此選項設置清除標記消息的方式。 _&lt; mode&gt;_ 可以是_逐字_，_空白_和_條帶_之一。 _條_模式是默認模式。 _逐字_模式根本不改變消息，_空格_只刪除前導/尾隨空白行，_條_刪除空白和評論。 ``` --create-reflog ``` 為標記創建reflog。要全局啟用標簽的reflog，請參見 [git-config [1]](https://git-scm.com/docs/git-config) 中的`core.logAllRefUpdates`。否定形式`--no-create-reflog`僅覆蓋較早的`--create-reflog`，但目前不會否定`core.logAllRefUpdates`的設置。 ``` --format=<format> ``` 一個字符串，用于插入顯示的標記ref中的`%(fieldname)`及其指向的對象。格式與 [git-for-each-ref [1]](https://git-scm.com/docs/git-for-each-ref) 的格式相同。未指定時，默認為`%(refname:strip=2)`。 ``` <tagname> ``` 要創建，刪除或描述的標記的名稱。新標簽名稱必須通過 [git-check-ref-format [1]](https://git-scm.com/docs/git-check-ref-format) 定義的所有檢查。其中一些檢查可能會限制標記名稱中允許的字符。 ``` <commit> ``` ``` <object> ``` 新標記將引用的對象，通常是提交。默認為HEAD。 ## 組態 默認情況下， _git標簽_處于默認簽名模式（-s）將使用您的提交者標識（`Your Name &lt;your@email.address&gt;`形式）來查找密鑰。如果要使用其他默認密鑰，可以在存儲庫配置中指定它，如下所示： ``` [user] signingKey = <gpg-keyid> ``` 僅在列出標簽時，即使用或暗示`-l`時，才會遵守`pager.tag`。默認是使用尋呼機。見 [git-config [1]](https://git-scm.com/docs/git-config) 。 ## 討論 ### 關于重新標記 當您標記錯誤的提交并且您想要重新標記時，您應該怎么做？ 如果你從未推過任何東西，只需重新標記即可。使用“-f”替換舊的。而且你已經完成了。 但是如果你把事情搞砸了（或者其他人可以直接讀取你的存儲庫），那么其他人就已經看到了舊的標簽了。在這種情況下，您可以執行以下兩項操作之一： 1. 理智的事情。只是承認你搞砸了，并使用不同的名字。其他人已經看過一個標簽名稱，如果你保持相同的名字，你可能會遇到兩個人都有“版本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`）。您通常需要來自另一端的標簽。 另一方面，如果你想要從其他人那里獲取一次性合并，那么你通常不希望從那里獲得標簽。這種情況更常發生在靠近頂層但不限于它們的人身上。當彼此拉扯時，凡人都不一定想要從另一個人那里自動獲得私人錨點標簽。 通常，郵件列表上的“請拉”消息只提供兩條信息：一個repo URL和一個分支名稱;這是為了在 _git fetch_ 命令行結束時輕松剪切和粘貼： ``` Linus, please pull from git://git..../proj.git master to get the following updates... ``` 變為： ``` $ git pull git://git..../proj.git master ``` 在這種情況下，您不希望自動關注其他人的標簽。 Git的一個重要方面是它的分布式特性，這在很大程度上意味著系統中沒有固有的“上游”或“下游”。從表面上看，上面的例子似乎表明標簽命名空間由人的上層所有，而且標簽只向下流動，但事實并非如此。它僅顯示使用模式確定誰對其標簽感興趣。 一次性拉動表示提交歷史現在正越過一個人圈之間的邊界（例如“主要對內核的網絡部分感興趣的人”），他們可能擁有自己的一組標簽（例如“這是來自網絡組的第三個候選版本被提議用于2.6.21版本的一般消費“）到另一個人群（例如”整合各種子系統改進的人“）。后者通常對前一組內部使用的詳細標簽不感興趣（這就是“內部”的含義）。這就是為什么在這種情況下不希望自動跟蹤標簽的原因。 很可能在網絡人員中，他們可能想要在他們的組內部交換標簽，但在該工作流程中，他們很可能通過具有遠程跟蹤分支來跟蹤彼此的進度。同樣，自動跟隨這些標簽的啟發式是一件好事。 ### 關于回溯標簽 如果您從另一個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 internal format ``` 它是`&lt;unix timestamp&gt; &lt;time zone offset&gt;`，其中`&lt;unix timestamp&gt;`是自UNIX紀元以來的秒數。 `&lt;time zone offset&gt;`是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`字符。 | 注意 | 此外，日期部分以下列格式接受：`YYYY.MM.DD`，`MM/DD/YYYY`和`DD.MM.YYYY`。 | ## 也可以看看 [git-check-ref-format [1]](https://git-scm.com/docs/git-check-ref-format) 。 [git-config [1]](https://git-scm.com/docs/git-config) 。 ## GIT 部分 [git [1]](https://git-scm.com/docs/git) 套件