Git 中文参考（三）（4）https://developer.aliyun.com/article/1565823
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 之一，该命令将创建 _ 标签 _ 对象，并需要标记消息。除非给出-m 或-F ，否则将启动编辑器以供用户键入标记消息。
如果给出-m 或-F 并且-a，-s和-u 不存在，则暗示-a。
否则，创建直接指向给定对象（即，轻量标签）的标签引用。
使用-s或-u 时，将创建 GnuPG 签名标记对象。如果未使用-u ，则使用当前用户的提交者标识来查找用于签名的 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>
< NUM>指定在使用-l 时打印注释的行数（如果有）。意味着--list。
默认情况下不打印任何注释行。如果-n没有给出编号，则只打印第一行。如果标记未注释，则显示提交消息。
-l
--list
列出标签。使用可选的...，例如git tag --list 'v-*'，仅列出与模式匹配的标记。
不带参数运行“git tag”也会列出所有标签。该模式是 shell 通配符（即，使用 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选项中指定的任何颜色。 字段必须是always，never或auto之一（如果不存在，则表现得好像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 ，则表示-a。
-F <file>
--file=<file>
从给定文件中获取标记消息。使用 - 从标准输入读取信息。如果没有给出-a，-s或-u ，则表示-a。
-e
--edit
从带有-F的文件和带有-m的命令行获取的消息通常用作未修改的标记消息。此选项允许您进一步编辑从这些来源获取的消息。
--cleanup=<mode>
此选项设置清除标记消息的方式。 < mode> 可以是 _ 逐字 ， 空白 _ 和 _ 条带 _ 之一。 _ 条 _ 模式是默认模式。 _ 逐字 _ 模式根本不改变消息，_ 空格 _ 只删除前导/尾随空白行，_ 条 _ 删除空白和评论。
--create-reflog
为标记创建 reflog。要全局启用标签的 reflog，请参见 git-config [1] 中的core.logAllRefUpdates。否定形式--no-create-reflog仅覆盖较早的--create-reflog，但目前不会否定core.logAllRefUpdates的设置。
--format=<format>
一个字符串，用于插入显示的标记 ref 中的%(fieldname)及其指向的对象。格式与 git-for-each-ref [1] 的格式相同。未指定时，默认为%(refname:strip=2)。
<tagname>
要创建，删除或描述的标记的名称。新标签名称必须通过 git-check-ref-format [1] 定义的所有检查。其中一些检查可能会限制标记名称中允许的字符。
<commit>
<object>
新标记将引用的对象，通常是提交。默认为 HEAD。
组态
默认情况下， _git 标签 _ 处于默认签名模式（-s）将使用您的提交者标识（Your Name 形式）来查找密钥。如果要使用其他默认密钥，可以在存储库配置中指定它，如下所示：
[user] signingKey = <gpg-keyid>
仅在列出标签时，即使用或暗示-l时，才会遵守pager.tag。默认是使用寻呼机。见 git-config [1] 。
讨论
关于重新标记
当您标记错误的提交并且您想要重新标记时，您应该怎么做？
如果你从未推过任何东西，只需重新标记即可。使用“-f”替换旧的。而且你已经完成了。
但是如果你把事情搞砸了（或者其他人可以直接读取你的存储库），那么其他人就已经看到了旧的标签了。在这种情况下，您可以执行以下两项操作之一：
- 理智的事情。只是承认你搞砸了，并使用不同的名字。其他人已经看过一个标签名称，如果你保持相同的名字，你可能会遇到两个人都有“版本 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）。您通常需要来自另一端的标签。
另一方面，如果你想要从其他人那里获取一次性合并，那么你通常不希望从那里获得标签。这种情况更常发生在靠近顶层但不限于它们的人身上。当彼此拉扯时，凡人都不一定想要从另一个人那里自动获得私人锚点标签。
通常，邮件列表上的“请拉”消息只提供两条信息：一个 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
它是 ，其中是自 UNIX 纪元以来的秒数。 是 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] 。 git-config [1] 。
GIT
部分 git [1] 套件
git-worktree
名称
git-worktree - 管理多个工作树
概要
git worktree add [-f] [--detach] [--checkout] [--lock] [-b <new-branch>] <path> [<commit-ish>] git worktree list [--porcelain] git worktree lock [--reason <string>] <worktree> git worktree move <worktree> <new-path> git worktree prune [-n] [-v] [--expire <expire>] git worktree remove [-f] <worktree> git worktree unlock <worktree>
描述
管理连接到同一存储库的多个工作树。
git 存储库可以支持多个工作树，允许您一次签出多个分支。使用git worktree add，新的工作树与存储库相关联。这个新的工作树称为“链接工作树”，而不是“git init”或“git clone”编写的“主工作树”。存储库有一个主要工作树（如果它不是裸存储库）和零个或多个链接工作树。完成链接的工作树后，使用git worktree remove将其删除。
如果在不使用git worktree remove的情况下删除工作树，则其关联的管理文件（位于下面的“详细信息”）最终将自动删除（请参阅 [git-config 中的gc.worktreePruneExpire [1] ]](https://git-scm.com/docs/git-config) ），或者您可以在主要或任何链接的工作树中运行git worktree prune来清理任何陈旧的管理文件。
如果链接的工作树存储在并非总是挂载的便携式设备或网络共享上，则可以通过发出git worktree lock命令来阻止其管理文件被修剪，可选择指定--reason来解释工作树被锁定的原因。
COMMANDS
add <path> [<commit-ish>]
创建并将签出到其中。新的工作目录链接到当前存储库，共享除工作目录特定文件（如 HEAD，索引等）之外的所有内容。-也可以指定为;它与@{-1}同义。
如果< commit-ish>是一个分支名称（称之为）并且未找到，并且既没有使用-b也没有-B或--detach，但是在一个远程中确实存在跟踪分支（称之为）使用匹配的名称，视为等效于：
$ git worktree add --track -b <branch> <path> <remote>/<branch>
如果分支存在于多个遥控器中，并且其中一个由checkout.defaultRemote配置变量命名，我们将使用该分支用于消除歧义，即使在所有遥控器中都不是唯一的。将其设置为例如如果不明确但存在于 _ 原点 _ 遥控器上，checkout.defaultRemote=origin总是从那里检出远程分支。另见 git-config [1] 中的checkout.defaultRemote。
如果省略并且既不使用-b也不使用-B和--detach，那么为方便起见，新工作树与以$(basename )命名的分支（称为）相关联。如果不存在，将自动创建基于 HEAD 的新分支，就像给出-b 一样。如果确实存在，它将在新的工作树中检出，如果它没有在其他任何地方检出，否则命令将拒绝创建工作树（除非使用--force）。
list
列出每个工作树的详细信息。首先列出主要工作树，然后列出每个链接的工作树。输出详细信息包括工作树是否裸露，当前检出的修订版，以及当前检出的分支（或者 _ 分离 HEAD_ ，如果没有）。
lock
如果工作树位于未始终安装的便携式设备或网络共享上，请将其锁定以防止其管理文件被自动修剪。这也可以防止它被移动或删除。 （可选）使用--reason指定锁定的原因。
move
将工作树移动到新位置。请注意，无法移动主工作树或包含子模块的链接工作树。
prune
修剪$ GIT_DIR / worktrees 中的工作树信息。
remove
删除一个工作树。只能删除干净的工作树（没有未跟踪的文件，也不会删除跟踪文件中的修改）。可以使用--force删除不干净的工作树或带子模块的工作树。无法删除主工作树。
unlock
解锁工作树，允许对其进行修剪，移动或删除。
OPTIONS
-f
--force
默认情况下，add拒绝创建新的工作树，当是分支名称并且已经被另一个工作树检出，或者已经分配给某个工作树但是丢失了（例如，如果被手动删除）。此选项会覆盖这些安全措施。要添加缺失但已锁定的工作树路径，请指定--force两次。
move拒绝移动锁定的工作树，除非指定了两次--force。
remove拒绝删除不干净的工作树，除非使用--force。要删除锁定的工作树，请指定--force两次。
-b <new-branch>
-B <new-branch>
使用add，从开始创建一个名为的新分支，并将签出到新的工作树中。如果省略，则默认为 HEAD。默认情况下，-b拒绝创建新分支（如果已存在）。 -B会覆盖此保护措施，将重置为。
--detach
使用add，在新工作树中分离 HEAD。请参见 git-checkout [1] 中的“DETACHED HEAD”。
--[no-]checkout
默认情况下，add检出，但是，--no-checkout可用于抑制检出以进行自定义，例如配置稀疏检出。请参见 git-read-tree [1] 中的“稀疏检出”。
--[no-]guess-remote
使用worktree add ，不使用，而不是从 HEAD 创建新分支，如果在一个与的基本名称匹配的远程中存在跟踪分支，则将新分支基于远程跟踪分支，并标记远程跟踪分支作为新分支的“上游”。
也可以使用worktree.guessRemote配置选项将其设置为默认行为。
--[no-]track
创建新分支时，如果是分支，则将其标记为新分支的“上游”。如果是远程跟踪分支，则这是默认值。有关详细信息，请参阅 git-branch [1] 中的“–track”。
--lock
创建后保持工作树锁定。这相当于git worktree add之后的git worktree lock，但没有竞争条件。
-n
--dry-run
使用prune时，不要删除任何东西;只需报告它将删除的内容。
--porcelain
使用list，以易于解析的格式输出脚本。无论用户配置如何，这种格式在 Git 版本中都将保持稳定。请参阅下文了解详情。
-q
--quiet
使用 _ 添加 _，禁止反馈消息。
-v
--verbose
使用prune，报告所有删除。
--expire <time>
使用prune，仅使未使用的工作树超过< time>。
--reason <string>
使用lock解释工作树被锁定的原因。
<worktree>
工作树可以通过路径来识别，无论是相对的还是绝对的。
如果工作树路径中的最后一个路径组件在工作树中是唯一的，则可以使用它来识别工作树。例如，如果你只有两个工作树，在“/ abc / def / ghi”和“/ abc / def / ggg”，那么“ghi”或“def / ghi”足以指向前工作树。
Git 中文参考（三）（6）https://developer.aliyun.com/article/1565825
