放行程序

Astropy当前的发布过程包括自动发布脚本和一些手动步骤的组合。未来的版本将自动化更多的过程，如果不是全部。

根据具体情况，有以下几种不同的程序：

• 标准放行程序

  • 测试版/发布候选版本的修改

• 执行功能冻结/分支新的主要版本

• 维护Bug修复版本

  • 从主服务器向后移植修复程序

  • 直接对错误修复分支进行修复

  • 准备发布bug修复分支

有关签名版本，请参阅 创建GPG签名密钥和签名标记 有关设置说明。

标准放行程序

这是发布Astropy（或使用完整错误修复/维护分支方法的附属包）的标准发布过程

1. 为下一个错误修复版本创建一个GitHub里程碑，从即将发布的版本中删除所有剩余的问题，并关闭该里程碑。发布主要版本时，也要关闭上一个维护分支上的最后一个里程碑。

   备注

   新里程碑的创建可以在您ping维护人员的相关请求时完成，这样维护人员就可以选择重新里程碑他们的工作。

2. 如果GitHub问题跟踪程序中有任何问题被标记为 affects-dev 但如果问题适用于此版本，请将其更新为 affects-release . 同样，如果此版本中还有任何问题没有解决，请将它们重新分配到下一个相关里程碑。

3. （仅适用于主要版本）确保更新“新增内容”部分，并提供有关问题、PRs和贡献者的统计信息。对于前两个 astropy-procedures repository 脚本 gh_issuereport.py 可以提供自上一个主要版本以来的数字。对于最后一个，你可能需要更新 Astropy .mailmap 文件，因为经常有贡献者在每次提交时都不小心使用相同的电子邮件地址。最简单的方法是运行命令 git shortlog -n -s -e 查看所有参与者及其电子邮件地址的列表。查找任何错误命名的条目或重复项，并将它们添加到 .mailmap 文件（与适当的规范名称/电子邮件地址匹配）完成此操作后，可以计算 git shortlog -s 以获得最终贡献者计数。

4. 同时，请务必更新 docs/credits.rst 文件以包含上述步骤中的任何新贡献者。（这一步只在主要版本上是必需的，但在时间允许的情况下，可以对bug修复版本执行此步骤。）

5. （astropy specific）通过将目录更改为，确保内置的IERS地球自转参数和闰秒表是最新的 astropy/utils/iers/data 执行 update_builtin_iers.sh . 检查结果 git diff （在 eopc04_IAU2000.62-now 文件更改；定期重新分析这些数据）并提交。

6. 确保您有一个GPG密钥对，当git需要对为发布创建的标记进行签名时可以使用。看到了吗 创建GPG签名密钥和签名标记 更多信息。

7. 获得 清洁的 的版本 astropy core repository . 也就是说，你没有任何中间构建文件。要么用新鲜的 git clone 或做 git clean -dfx .

8. 确保您所在的分支与即将发布的版本相匹配。例如，如果发布版本1.2.2，请确保：

   $ git checkout v1.2.x
   

9. 确保持续集成服务(例如，GitHub操作或CircleCI)传递给 astropy core repository 树枝，你要释放它。还要检查是否 Azure core package pipeline 它把轮子建在 v* 树枝正在经过。您可能还希望在本地运行测试(启用远程数据以确保所有测试实际运行)，使用TOX在隔离环境中进行彻底测试：

   $ pip install tox --upgrade
   $ TEST_READ_HUGE_FILE=1 tox -e test-alldeps -- --remote-data=any
   

10. 编辑 CHANGES.rst 将要发布的版本的日期从“未发布”更改为今天的日期。还要确保删除该版本的变更日志中没有条目的任何部分。对于发布候选之后的发布 (测试版/发布候选版本的修改 )，changelog部分的标题也应该被替换，这样就不再提到发布候选版本了。然后添加并提交这些更改：

    <use your favorite editor on CHANGES.rst>
    $ git add CHANGES.rst
    $ git commit -m "Finalizing changelog for v<version>"
    

11. 将分支推回到GitHub，例如：

    $ git push upstream v1.2.x
    

    并确保上述CI服务（包括Azure管道）仍在通过。

    备注

    您可能需要更换 upstream 这里有 astropy 或者你用的任何远程名称 astropy core repository .

12. 使用标记提交 v<version> 一定要有标记 -s 选项：

    $ git tag -s v<version> -m "Tagging v<version>"
    

13. 把标签推到 astropy core repository ：：

    $ git push upstream v<tag version>
    

    备注

    您可能需要更换 upstream 这里有 astropy 或者你用的任何远程名称 astropy core repository . 另外，使用 --tags 参数 git push ，但这应该 not 这样做吧，因为它可能会推高一些意外的标记。

    在这一点上，如果一切顺利，轮子和sdist将建立在 Azure core package pipeline 上传到PyPI！

14. 如果标记的控制盘构建有任何问题（如果它传递给发布分支，则不应该发生这种情况），那么您必须修复任何问题。首先，您需要撤销发布过程，删除为发布所做的提交并删除您创建的标记：

    $ git reset --hard HEAD^^^^ # you could also use the SHA hash of the commit before your first changelog edit
    $ git tag -d v<version>
    

    备注

    此后，任何将同一个标记重新推出GitHub的行为都将是一种强制推送。

一旦sdist和wheels被上传，发布就完成了！

祝贺 你！您已完成释放！现在只有几个清理任务来完成这个过程。

放行后程序

1. 返回发布分支（例如。， 1.2.x )并更新 CHANGES.rst 为下一个版本添加新节。然后添加并提交：

   $ git checkout v1.2.x
   <use your favorite editor on CHANGES.rst>
   $ git add CHANGES.rst
   $ git commit -m "Add v<next_version> to the changelog"
   

2. 将这些更改推到 astropy core repository ：：

   $ git push upstream v<version branch>.x
   

3. 如果这是当前版本的一个版本（即，不是一个较新版本支持的LTS），请更新“stable”分支以指向新版本：

   $ git checkout stable
   $ git reset --hard v<version>
   $ git push upstream stable --force
   

4. 更新Readthedocs，以便它为您刚刚发布的版本生成文档。您可以在“admin”选项卡中找到它，每个github标记旁边都有复选框。同时验证 stable Readthedocs版本为新版本正确构建（完成上一步后，它应该自动触发）。

5. 发布修补程序版本时，还应将发行历史记录中以前的RTD版本设置为“受保护”。例如，在发布v1.1.2时，将v1.1.1设置为“protected”。这可以防止以前的版本将用户在版本下拉列表中看到的版本列表弄乱（但是以前的版本仍然可以通过URL访问）。

6. 通过编辑 index.html 页码https://github.com/astropy/astropy.github.com通过更改“当前版本”链接和/或更新旧版本列表（如果这是LTS错误修复或新的主要版本）。如果您更新了 docs/credits.rst 一开始。

7. 给 Astropy 开个 master 分支以更新 CHANGES.rst 以反映您刚刚执行的发布日期，并包含变更日志的新部分。通常最简单的方法是使用 git cherry-pick changelog在上面的发布提交之前提交。如果您不确定如何执行此操作，则最好复制并粘贴维护分支的相关部分 CHANGES.rst 变成主人。在同样的公关中，你也要更新 docs/whatsnew/index.rst 和 docs/whatsnew/X.Y.rst 以现有文本为例，链接到已发布的RTD分支中的“新增功能”文档。

8. conda-forge 有一个机器人可以自动从一个新的PyPI（稳定）版本中打开一个PR，您需要跟踪并合并它。同时，对于LTS版本，您仍然需要在 astropy-feedstock . 这与车轮的过程类似。当 conda-forge 包准备好了，给Anaconda的维护人员发电子邮件，告诉他们发布的内容，这样他们就可以更新默认频道中的版本了。通常，您应该等待以确保 conda-forge 而且可能 conda 在发布公告之前工作（这样，想要试用新版本的用户可以使用 conda ）

9. 更新 LATEST_ASTROPY_STABLE 或 ASTROPY_LTS_VERSION 中的变量 ci-helpers 存储库一旦 conda 软件包可用。

10. 上传发布到Zenodo。这必须手动完成，因为Zenodo/GitHub集成依赖于在GitHub上发布版本，而我们没有做到这一点。所以对于Astropy核心包，使用Astropy团队证书登录Zenodo，然后转到 existing record 是的。点击 新版本 -请注意，重要的是这样做，而不是作为一个全新的记录上传发布。现在您应该看到一个预填的存款表，其中包含以前版本的详细信息。首先删除 文件夹 部分，然后单击 选择文件 并选择 tar.gz 要上载的核心包版本的版本文件，然后单击 开始上传 . 在发布之前，表单中有几个字段需要更新： 出版日期 应该设置为tar文件上载到PyPI的日期 书名 应更新以包含新版本号，并且 版本 应更新以包含版本号（无 v 前缀）。一旦您对更改感到满意，请单击 Save 然后 出版 .

11. 一旦默认版本可用 conda 频道，准备公告。使用以前的公告作为模板，但链接到release标记，而不是 stable . 对于一个新的主要版本，您应该与Astropy协调员协调。同时，对于错误修复版本，您可以继续向 astropy-dev 还有一堆乱七八糟的邮件列表。

测试版/发布候选版本的修改

对于主要版本，我们做beta和/或发布候选版本，以便在真正发布之前有机会捕捉到重要的bug。如果您正在执行的发布是这种预发布，那么需要修改上面的一些步骤。

发布程序的主要修改是：

• 输入标记版本时，包括 b? 或 rc?? 版本号后面的后缀，例如“1.2b1”或“1.2rc1”。您必须遵循此编号规则 (X.Yb# 或 X.Y.Zrc# )，因为它将确保发布是由各种自动化工具“在”主发布之前”排序的，并且还告诉PyPI这是一个“预发布”

• 请勿执行步骤 放行后程序 .

一旦发布候选版本可用，请在下面创建一个新的Wiki页面 Astropy Project Wiki 标题为“vX.Y RC testing”（将“X.Y”替换为版本号），使用 wiki of a previous RC 作为模板。

执行功能冻结/分支新的主要版本

如中所述 APE2 ，astropy发布会定期进行，但功能冻结发生在实际发布之前。功能冻结也是主分支的开发与新的主要版本的维护分支分离的时候。这使得下一个主要版本的新开发可以继续进行，而即将发布的版本可以专注于bug修复和文档更新。

这一过程很简单：

1. 从github将本地主分支更新为最新版本：

   $ git fetch upstream --tags
   $ git checkout -B master upstream/master
   

2. 在要冻结要素的点处从主节点创建新分支：：

   $ git branch v<version>.x
   

3. 更新 CHANGES.rst 在下一个主要版本的最上面添加一个新的部分。然后添加并提交这些更改：

   <use your favorite editor on CHANGES.rst>
   $ git add CHANGES.rst
   $ git commit -m "Add <next_version> to changelog"
   

4. 使用下一个主版本标记此提交，后跟 .dev . 例如，如果您刚刚分支 4.0 ，创建 v4.1.dev 在提交上添加 4.1 更改日志部分：

   $ git tag -s "v<next_version>.dev" -m "Back to development: v<next_version>"
   

5. 同时更新文档的“新增功能”部分，以包含下一个主要版本的部分。例如。：：

   $ cp docs/whatsnew/<current_version>.rst docs/whatsnew/<next_version>.rst
   

   然后需要编辑 docs/whatsnew/<next_version>.rst ，删除所有内容，但保留基本结构。您可能还需要将“by the numbers”替换为“xxx”，以提醒您在下一个版本之前更新它们。然后将新版本添加到 docs/whatsnew/index.rst ，更新中的引用 docs/index.rst 指向该版本，并提交这些更改：

   $ git add docs/whatsnew/<next_version>.rst
   $ git add docs/whatsnew/index.rst
   $ git add docs/index.rst
   $ git commit -m "Added <next_version> whats new section"
   

6. 将所有这些更改推送到github:：

   $ git push upstream v<version>.x:v<version>.x
   $ git push upstream master:master
   

   备注

   您可能需要更换 upstream 这里有 astropy 或者你用的任何远程名称 astropy core repository .

7. 在github问题跟踪程序上，为下一个主要版本添加一个新的里程碑。

维护Bug修复版本

备注

总是从LTS发行版开始，然后，如果需要的话，为稳定的发行版修复一个错误。如果发布不是按照这个顺序完成的，那么关于什么地方的变更日志条目可能会混淆。

Astropy发行版，正如大多数Python项目推荐的那样，遵循<major><minor><micro>版本方案，其中“micro”版本也称为“bug修复”版本。Bug修复版本不应该改变任何用户可见的界面。它们应该只修复先前主/次发行版上的错误，还可能重构内部API或包含以前版本中的遗漏——也就是说，那些被记录为存在的特性，但在上一版本中被意外地遗漏了。它们还可能包括对docstring的更改，以增强清晰度，但不描述新功能（例如，更多示例、排印错误修复等）。

Bug修复发布通常是通过维护一个或多个与主分支分离的Bug修复分支来管理的（下面的发布过程讨论了如何创建这些分支）。通常，只要在Astropy主分支上修复了一个问题，就必须决定这是否是一个应该包含在Astropy错误修复版本中的修复。通常这个问题的答案是“是”，尽管有些问题可能不适用于bug修复分支。例如，不必将修复后传给在首次创建bug修复分支时不存在的新特性。新特性永远不会合并到bug fix分支中——只有bug fixes；因此得名。

在极少数情况下，错误修复可以直接进入错误修复分支，而不必首先进入主分支。如果对开发版本中已删除或重写的功能进行了修复，并且不再修复该问题，则可能会发生这种情况。但是，根据bug的严重程度，可能值得将其包含在bug修复版本中，因为某些用户可能会因为API更改而缓慢地升级到新的主/微版本。

通过GitHub问题跟踪程序中的里程碑特性，问题被分配到一个Astropy版本中。在任何给定的时间，至少有两个版本在开发中：下一个主要/次要版本和下一个bug修复版本。例如，在撰写本文时，有两个发布里程碑处于打开状态：v1.2.2和v0.3.0。在下一个版本中，所有的问题都应该在1.2版本中得到修正。实现新特性的任何问题都将进入v0.3.0里程碑——这是主分支中不应该后端口的任何工作。有关使用里程碑的更详细指南，请参阅 使用里程碑和标签 .

从主服务器向后移植修复程序

备注

The changelog script in astropy-procedures (pr_consistency scripts in particular) does not know about minor releases, thus please be careful. For example, let's say we have two branches (master and v1.2.x). Both 1.2.0 and 1.2.1 releases will come out of the same v1.2.x branch. If a PR for 1.2.1 is merged into master before 1.2.0 is released, it should not be backported into v1.2.x branch until after 1.2.0 is released, despite complaining from the aforementioned script. This situation only arises in a very narrow time frame after 1.2.0 freeze but before its release.

大多数修复都是使用 git cherry-pick 命令，它像补丁一样应用单个提交的差异。为了举例说明，假设当前的bug fix分支是“v1.2.x”，并且在提交过程中在master中修复了一个bug abcd1234 . 为了回输修复程序，请检查v1.2.x分支（确保它与 astropy core repository )切利选择合适的承诺：

$ git checkout v1.2.x
$ git pull upstream v1.2.x
$ git cherry-pick abcd1234

有时候，一个关键的选择并不能很好地应用，因为bug修复分支代表了不同的开发路线。这可以像任何其他合并冲突一样解决：手动编辑冲突的文件，然后运行 git commit 并接受默认的提交消息。如果cherry选择的修复在单独的提交中有一个相关联的changelog条目，那么也要确保将其后传。

如果问题需要多个提交才能修复，该怎么办？这有几种可能。最简单的方法是，如果修复是以合并到主分支中的pull请求的形式出现的。无论何时GitHub合并一个pull请求，它都会在主分支中生成一个合并提交。此合并提交表示 full 拉取请求中所有提交组合的差异。这意味着只需要选择合并提交（这需要添加 -m 1 cherry pick命令的选项）。例如，如果 5678abcd 是合并提交：

$ git checkout v1.2.x
$ git pull upstream v1.2.x
$ git cherry-pick -m 1 5678abcd

事实上，由于Astropy强调基于请求的工作流，这是 most 用于后移植bug修复的常见场景，以及需要最少考虑的场景。但是，如果您不是在处理一个不是作为拉请求引入的修复，请继续阅读。

参见

合并提交和cherry picks 进一步解释cherry pick命令以及它如何与合并提交一起工作。

如果不仔细选择合并提交，还有其他方法可以处理多个提交。最简单的，虽然可能很乏味，但是对于每个提交，按照正确的顺序运行cherry pick命令一次。但是，从Git 1.7.2开始，可以合并一系列提交，如下所示：

$ git cherry-pick 1234abcd..56789def

只要您要选择的提交实际上彼此一致，这就可以正常工作。在大多数情况下都是这样，尽管一些bug修复将涉及后续提交，这些提交也需要后端口。大多数错误修复都会在问题跟踪器中有一个与之相关的问题，因此请确保在提交消息中引用与该问题相关的所有提交。这样，对于需要从后端口导入的提交来说就更难避免丢失。

直接对错误修复分支进行修复

正如本节前面提到的，在某些情况下，修复只适用于bug修复版本，而不适用于主线开发。在这种情况下，有两种选择：

1. 一个拥有提交权限的Astropy开发人员 astropy core repository 可以检查bug修复分支并提交并直接推送您的修复。

2. 最好 ：您也可以通过GitHub针对bug修复分支而不是针对master发出请求。通常情况下，当您从叉上的分支向 astropy core repository ，GitHub将你的分支比作Astropy的主人。如果您查看拉请求页面的左侧，在“baserepo:astropy/astropy”下有一个标签为“basebranch:master”的下拉列表。您可以单击此下拉列表，然后选择bug fix分支（例如“v1.2.x”）。然后，GitHub会将您的修复与该分支进行比较，并在PR被接受时合并到该分支中。

准备发布bug修复分支

在创建bug修复版本之前，需要执行两个主要步骤。其余步骤与中描述的任何其他版本相同 标准放行程序 （尽管一定要提供正确的版本号）。

1. 对于分配给发布里程碑（以及旧的LTS版本，如果有的话）的问题的任何现有修复都必须在发布之前包含在维护分支中。

2. Astropy变更日志必须更新以列出为当前版本修复的所有问题——尤其是用户可见的问题。变更日志应该在主分支中更新，然后合并到错误修复分支中。大多数问题 应该 已经有它们的变更日志条目。但有时这些会被遗忘，所以如果还不存在，请在后端口过程中添加一个。看到了吗 更新和维护变更日志 了解更多详细信息。

为了帮助这个过程，在 astropy-procedures repository ，在 pr_consistency 目录。这些脚本基本上检查是否满足上述两个条件。这些脚本的详细文档在它们的存储库中给出，但是这里我们总结了基本的工作流程。按顺序运行脚本（它们是编号的 1.<something>.py ， 2.<something>.py ，等），根据需要输入github登录凭据（如果要多次运行它们，请使用 ~/.netrc 建议使用文件-请参阅 this Stack Overflow post 关于如何做到这一点的更多信息，或者 a similar github help page ). 应该检查一致性：实际上应该运行脚本：

$ python 4.check_consistency.py > consistency.html

它将生成一个简单的web页面，其中显示了pull请求合并到master中但是 not 在相关版本中，它已经被修改，以及任何变更日志的不规则性（即，pr在github里程碑所指示的错误部分）。你要纠正这些不规则的地方 第一 在启动后端口进程之前（根据需要按顺序重新运行脚本）。

最后 consistency.html 页面将显示一系列 git cherry-pick 用于使用使里程碑和分支保持一致所需的pr更新维护分支的命令。确保您在正确的维护部门，例如。，

$ git checkout v1.3.x
$ git pull upstream v1.3.x  # Or possibly a rebase if conflicts exist

如果您正在为1.3.x系列进行错误修复。按照上面描述的cherry picking过程，一次执行一个命令。如果出于某种原因，您确定github里程碑出错，并且无法进行后台移植，请在github上重新标记该问题，然后继续。此外，无论何时，当你回传一个公关，在这个问题上留下一个评论是很有用的，比如“将它后传到v1.3.x as<SHA>”，这样就可以清楚地看到，这背后的事件发生在其他人身上。

警告

自动化脚本从来都不是完美的，它可能会漏掉需要后端口的问题，或者在某些情况下会报告误报。

在最终确定bug修复版本之前，最好查看一下GitHub在发布里程碑中关闭的问题列表，并检查每个问题在bug修复分支中是否都有修复。通常，一个快速的方法是运行每个问题：

$ git log --oneline <bugfix-branch> | grep #<issue>

大多数修复都会在提交消息中提到它们的相关问题，因此这往往是非常可靠的。但是，有些问题不会显示在提交日志中，因为它们的修复是在一个单独的请求中进行的。通常，GitHub通过将问题与PR交叉引用来明确这一点。

最后，不是所有分配给发布里程碑的问题都需要在发布之前得到修复。通常，为了在某个计划内获得一个带有现有修复的版本，最好将那些不能很快修复的问题分到新的发布里程碑。如果即将发布的bug修复版本是“v1.2.2”，那么继续创建一个“v1.2.3”里程碑，并重新分配任何在“v1.2.2”中无法及时修复的问题。

创建GPG签名密钥和签名标记

执行发布的主要步骤之一是在git存储库中创建一个标记，该标记表示存储库的确切状态，表示正在发布的版本。对于 Astropy 我们将永远使用 signed tags ：已签名的标记用签名者的姓名和电子邮件地址、日期和时间以及标记中代码的校验和进行批注。然后使用GPG私钥对该信息进行签名，并将其存储在存储库中。

使用已签名的标记可确保该标记的内容在将来的完整性。任何人都可以很容易地在vc1.0上创建一个标签。但是只有一个“0.1”将由一个超级项目协调员签署，并且可以用他们的公钥进行验证。

生成公钥/私钥对

Git使用GPG创建签名标记，因此为了执行Astropy版本，您需要安装GPG，并且必须生成签名密钥对。大多数 * 默认情况下，NIX安装随GPG一起安装（因为它用于验证系统包的完整性）。如果你没有 gpg 命令，请参阅系统的文档以了解如何安装它。

对于OSX，可以使用从MacPorts安装GPG sudo port install gnupg .

要创建新的公钥/私钥对，请运行：

$ gpg --gen-key

这将带您完成几个交互式步骤。对于加密和过期设置，使用默认设置应该是安全的（我使用4096的密钥大小，只是因为多出几个千字节会造成什么伤害？）输入您的全名，最好包括您的中间名或中间名首字母，以及您希望在相当长的时间内处于活动状态的电子邮件地址。请注意，此名称和电子邮件地址必须与您作为git配置提供的信息相匹配，因此您应该在创建密钥时选择相同的名称/电子邮件地址，或者更新git配置以匹配密钥信息。最后，选择一个非常好的密码短语，它不会轻易受到暴力攻击。

如果您希望在一段时间内使用同一密钥，最好同时备份公钥和私钥：

$ gpg --export --armor > public.key
$ gpg --export-secret-key --armor > private.key

将这些文件备份到一个可信的位置——最好是一个一次性写入的物理介质，可以安全地存储在某个地方。人们还可以将他们的密钥备份到可信的在线加密存储中，尽管有些人可能觉得不够安全——这取决于你自己和你是否满意。

将公钥添加到密钥服务器

现在你有了一个公钥，你可以在任何你喜欢的地方发布它——在你的电子邮件中，在公共代码库中，等等。你也可以把它上传到一个专用的公共OpenPGP密钥服务器上。这将无限期地存储公钥（直到您手动撤消它），并将自动与世界各地的其他密钥服务器同步。这使得使用gpg命令行工具检索公钥变得非常容易。

为此，您需要公钥的密钥名。要查找此输入：

$ gpg --list-keys

这将输出如下内容：

/path/to/.gnupg/pubring.gpg
---------------------------------------------
pub   4096D/1234ABCD 2012-01-01
uid                  Your Name <your_email>
sub   4096g/567890EF 2012-01-01

以“pub”开头的行上的8位十六进制数字，在本例中是公钥的“1234ABCD”唯一密钥名。要将其推送到密钥服务器，请输入：

$ gpg --send-keys 1234ABCD

但将1234ABCD替换为公钥的密钥名。大多数系统都配置了一个合理的默认keyserver，因此您不必指定更多的值。

创建标记

现在测试在git中创建签名标记。这样做是安全的——您可以在将标记推送到远程存储库之前删除它：

$ git tag -s v0.1 -m "Astropy version 0.1"

这将要求密码来解锁您的私钥，以便用它来签署标签。请确认git选择的默认签名密钥是正确的（如果只有一个密钥，则会是正确的）。

创建标记后，可以使用以下命令进行验证：

$ git tag -v v0.1

这应该输出如下内容：

object e8e3e3edc82b02f2088f4e974dbd2fe820c0d934
type commit
tag v0.1
tagger Your Name <your_email> 1339779534 -0400

Astropy version 0.1
gpg: Signature made Fri 15 Jun 2012 12:59:04 PM EDT using DSA key ID 0123ABCD
gpg: Good signature from "Your Name <your_email>"

只要密钥环中有签名者的公钥，就可以使用它来验证来自任何存储库的签名标记。在本例中，您自己签署了标记，因此您已经有了公钥。

请注意，如果您计划按照以下步骤进行发布，那么您将希望删除刚刚创建的标记，因为发布脚本会为您完成此操作。您可以通过执行以下操作删除此标记：

$ git tag -d v0.1