一旦你创建了一个本地模块并准备好让其他用户使用它，是时候发布你的模块了。由于 Go modules 从它们存储的相同代码仓库分发，你需要将代码提交到本地 Git 仓库，并推送到 github.com/your_github_username/pubmodule 的仓库。

在将代码提交到本地 Git 仓库之前，最好确保不会提交任何你不期望提交的文件，否则当你将代码推送到 GitHub 时，这些文件将被公开发布。在 pubmodule 目录中使用 git status 命令将显示所有将被提交的文件和更改：

git status

输出将类似于此：

Output
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	go.mod
	pubmodule.go

你应该会看到 go mod init 命令创建的 go.mod 文件，以及你创建 Hello 函数的 pubmodule.go 文件。根据你创建仓库的方式，分支名称可能与此输出不同。最常见的分支名称是 main 或 master。

当你确认只有你想要的文件时，可以使用 git add 暂存文件，并使用 git commit 将它们提交到仓库：

git add .
git commit -m "Initial Commit"

输出将类似于此：

Output
[main (root-commit) 931071d] Initial Commit
 2 files changed, 8 insertions(+)
 create mode 100644 go.mod
 create mode 100644 pubmodule.go

最后，使用 git push 命令将模块推送到 GitHub 仓库：

git push

输出将类似于此：

Output
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 367 bytes | 367.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:your_github_username/pubmodule.git
 * [new branch]      main -> main

运行 git push 命令后，你的模块将被推送到仓库，现在任何人都可以使用它。如果没有发布任何版本，Go 将使用仓库默认分支中的代码作为模块的代码。默认分支名称是 main、master 或其他无关紧要，重要的是仓库的默认分支设置。

在本节中，你将创建的本地 Go 模块发布到 GitHub 仓库，使其他人可以使用它。虽然你现在有一个已发布的模块，但维护公共模块的另一部分是确保模块用户可以使用其稳定版本。你可能希望以后对模块进行更改并添加功能，但如果你在不使用版本的情况下进行这些更改，可能会意外破坏使用你模块的某人代码。为了解决这个问题，当开发达到新里程碑时，你可以为模块添加版本。不过，在添加新版本时，请确保选择有意义的版本号，以便用户知道是否可以立即升级。

一个有意义的版本号能让用户了解他们交互的公共接口或 API 发生了多大变化。Go 通过一种称为语义化版本控制（semantic versioning，或简称“SemVer”）的版本方案来传达这些变化。（语义化版本控制使用版本字符串来传达代码变化的含义，这就是语义化版本控制名称的由来。）Go 的模块系统遵循 SemVer 来判断哪些版本比您当前使用的版本更新，以及模块的新版本是否安全自动升级。

语义化版本控制为版本字符串中的每个数字赋予了特定含义。SemVer 中的典型版本包含三个主要数字：主版本号（major version）、次版本号（minor version）和补丁版本号（patch version）。这些数字用 . 组合形成版本，例如 1.2.3。数字的顺序是主版本号在前、次版本号在中间、补丁版本号在后。这样，当查看版本时，您可以看出哪个更新，因为特定位置的数字比之前版本更高。例如，2.2.3 比 1.2.3 更新，因为主版本号更高。同样，1.4.3 比 1.2.10 更新，因为次版本号更高。尽管补丁版本号 10 高于 3，但次版本号 4 高于 2，因此次版本号优先。当版本字符串中的某个数字增加时，其后的所有部分都会重置为 0。例如，将 1.3.10 的次版本号增加会得到 1.4.0，将 2.4.1 的主版本号增加会得到 3.0.0。

使用这些规则，Go 可以在您运行 go get 时确定使用模块的哪个版本。例如，假设您的项目使用模块 github.com/your_github_username/pubmodule 的 1.4.3 版本。如果您希望 pubmodule 保持稳定，您可能只想自动升级补丁版本号（即 .3）。如果您运行命令 go get -u=patch github.com/your_github_username/pubmodule，Go 会看到您想升级模块的补丁版本号，并且只会查找以 1.4 作为主版本号和次版本号部分的新版本。

在为模块创建新版本发布时，重要的是要考虑模块的公共 API 发生了什么变化。语义化版本字符串的每个部分都向您和您的用户传达了 API 变化的范围。这些变化通常分为三种类别，与版本的每个组成部分相对应。最小的变化会增加补丁版本号，中等规模的变化会增加次版本号，而最大的变化会增加主版本号。使用这些类别来确定要增加哪个版本号，将帮助您避免破坏自己的代码以及依赖您模块的其他人的代码。

主版本号

SemVer 版本中的第一个数字是主版本号（1.4.3）。在发布模块新版本时，主版本号是最重要的数字需要考虑的。主版本号变化用于表示公共 API 的向后不兼容变化。向后不兼容变化是指模块中的任何变化，如果用户升级而不做其他更改，就会导致他们的程序崩溃。崩溃可能意味着从构建失败（因为函数名已更改），或者库的工作方式改变，导致相同的方法返回 "v1" 而不是 "1"。不过，这仅适用于您的公共 API，即其他人可能使用的导出的类型或方法。如果版本仅包含用户不会注意到的改进，则不需要主版本号变化。记住哪些变化属于此类别的方法是：任何被视为“更新”或“删除”的变化都属于主版本号增加。

以以下代码为例，展示主版本号变化可能的样子。您有一个名为 UserAddress 的函数，目前接受一个 string 参数并返回一个 string：

func UserAddress(username string) string {
	// 以字符串形式返回用户地址
}

虽然该函数目前返回 string，但您可能认为如果函数返回像 *Address 这样的 struct 会更好。这样您可以包含已分离的额外数据，例如邮政编码：

type Address struct {
	Address    string
	PostalCode string
}

func UserAddress(username string) *Address {
	// 返回用户地址和邮政编码的 struct
}

这是一个主版本号变化的示例，因为它要求您的用户修改自己的代码才能使用。同样，如果您决定完全移除 UserAddress，用户也需要更新代码以使用替代品，这也是主版本号变化。

另一个主版本号变化的示例是向 UserAddress 函数添加新参数，即使它仍返回 string：

func UserAddress(username string, uppercase bool) string {
	// 以字符串形式返回用户地址，如果 bool 为 true 则大写
}

由于此变化也要求使用 UserAddress 函数的用户更新代码，因此也需要主版本号增加。

不过，您对代码所做的并非所有变化都如此剧烈。有时您会对公共 API 进行添加新函数或值但不更改现有内容的更改。

次版本号

SemVer 版本中的第二个数字是次版本号（1.4.3）。次版本号变化用于表示公共 API 的向后兼容变化。向后兼容变化是指不影响当前使用您模块的代码或项目的任何变化。与主版本号类似，这仅影响您的公共 API。记住哪些变化属于此类别的方法是：任何被视为“添加”的变化，但不是“更新”。

使用主版本号示例中的相同例子，想象您有一个返回 string 的名为 UserAddress 的方法：

func UserAddress(username string) string {
	// 以字符串形式返回用户地址
}

不过这一次，不是更新 UserAddress 以返回 *Address，您决定添加一个全新的名为 UserAddressDetail 的方法：

type Address struct {
	Address    string
	PostalCode string
}

func UserAddress(username string) string {
	// 以字符串形式返回用户地址
}

func UserAddressDetail(username string) *Address {
	// 返回用户地址和邮政编码的 struct
}

添加这个新的 UserAddressDetail 函数不会要求用户在更新到此模块版本时进行更改，因此被视为次版本号增加。他们可以继续使用 UserAddress，仅当他们希望包含 UserAddressDetail 的额外信息时才需要更新代码。

不过，公共 API 变化很可能不是您发布模块新版本的唯一原因。Bug 是软件开发中不可避免的一部分，补丁版本号就是用来修补这些漏洞的。

补丁版本号

补丁版本号是 SemVer 版本中的最后一个数字（1.4.3）。补丁版本号变化是不影响模块的公共 API的任何变化。不影响模块公共 API 的变化通常是 bug 修复或安全修复。再使用前述示例中的 UserAddress 函数，假设模块的一个版本在函数返回的 string 中缺少地址的一部分。如果您发布新版本来修复该 bug，则只会增加补丁版本号。该版本不会包含用户使用 UserAddress 公共 API 的方式变化，仅返回数据的正确性。

如本节所示，仔细选择新版本号是赢得用户信任的重要方式。使用语义化版本控制可以向用户显示更新到新版本所需的工作量，并且您不会意外用破坏他们程序的更新惊吓他们。在考虑对模块所做的更改并确定下一个版本号后，您可以发布新版本并使其可供用户使用。

在发布模块的新版本之前，你需要先用计划要做的更改更新你的模块。如果没有任何更改，你将无法确定要增加语义化版本的哪一部分。对于本教程中的模块，你将添加一个新的 Goodbye 方法来补充 Hello 方法，然后发布这个新版本供用户使用。

首先，打开 pubmodule.go 文件，并将新的 Goodbye 方法添加到你的 public API 中：

package pubmodule

func Hello() string {
  return "Hello, You!"
}

func Goodbye() string {
  return "Goodbye for now!"
}

保存更改后，你可以通过运行 git status 来检查哪些更改预计会被提交：

git status

输出将类似于这样，显示你的模块中唯一的更改是你添加到 pubmodule.go 的方法：

Output
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   pubmodule.go

no changes added to commit (use "git add" and/or "git commit -a")

接下来，使用 git add 和 git commit 将更改添加到暂存文件中并提交到你的本地仓库：

git add .
git commit -m "Add Goodbye method"

输出将类似于这样：

Output
[main 3235010] Add Goodbye method
 1 file changed, 4 insertions(+)

更改提交后，你需要将它们推送到你的 GitHub 仓库。在更大的软件项目中，或者与其他开发者协作时，这个步骤通常会有所不同。在开发新功能时，开发者会创建一个 Git 分支来存放更改，直到新功能稳定并准备发布。这时，另一个开发者会审查分支中的更改，以提供第二双眼睛，可能发现第一个开发者遗漏的问题。审查完成后，该分支会合并到默认分支（如 master 或 main）。在两次发布之间，默认分支会累积这些类型的更改，直到发布新版本的时候。

由于你的模块这里不经过这个过程，将你所做的更改推送到仓库将模拟更改的累积：

git push

输出将类似于这样：

Output
numerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 369 bytes | 369.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:your_github_username/pubmodule.git
   931071d..3235010  main -> main

输出显示新代码已在默认分支中准备好供用户使用。

到目前为止，你所做的一切与最初发布模块时相同。然而，现在发布新版本的重要部分来了：选择新版本号。

如果你查看对模块所做的更改，public API（实际上是任何更改）的唯一变化是向模块添加了 Goodbye 方法。由于用户可以从仅包含 Hello 函数的先前版本更新，而无需在其自身进行更改，此更改将是向后兼容的更改。在语义化版本控制中，对 public API 的向后兼容更改意味着次版本号增加。不过，这是你模块的第一个发布版本，因此没有先前版本可以增加。如果你将 0.0.0 视为“无版本”，那么递增次版本将引导你到版本 0.1.0，即模块的下一个版本。

现在你有了要赋予模块发布版本的版本号，你可以使用它结合 Git tags 来发布新版本。当开发者使用 Git 跟踪源代码时，即使在非 Go 语言中，常见约定是使用 Git 的 tags 来跟踪特定版本发布的代码。这样，如果他们需要对旧版本进行更改，可以使用该 tag。由于 Go 已经从源仓库下载模块，它通过使用相同的版本 tags 来利用这一做法。

要使用这些 tags 发布你自己模块的新版本，你将使用 git tag 命令为你要发布的代码打上标签。作为 git tag 命令的参数，你还需要提供版本 tag。要创建版本 tag，以前缀 v（表示 version）开头，紧接着添加你的 SemVer。对于你的模块，最终的版本 tag 将是 v0.1.0。现在，运行 git tag 为你的模块打上版本 tag：

git tag v0.1.0

版本 tag 在本地添加后，你仍需要将其推送到你的 GitHub 仓库，可以使用 git push 配合 origin 来完成：

git push origin v0.1.0

git push 命令成功后，你将看到已创建一个新 tag v0.1.0：

Output
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To github.com:your_github_username/pubmodule.git
 * [new tag]         v0.1.0 -> v0.1.0

上面的输出显示你的 tag 已推送，你的 GitHub 仓库有一个新的 v0.1.0 tag 可供你的模块用户引用。

现在你已经使用 git tag 发布了模块的新版本，每当用户运行 go get 获取模块的最新版本时，它将不再基于默认分支的最新 commit hash 下载版本。一旦模块有了发布版本，go 工具将开始使用这些版本来确定更新模块的最佳方式。结合语义化版本控制，这允许你迭代和改进模块，同时为用户提供一致且稳定的体验。

在本教程中，您创建了一个公开的 Go module，并将其发布到 GitHub 仓库，以便其他人可以使用它。您还使用了 semantic versioning 来确定模块的最佳版本号。最后，您扩展了模块的功能，并使用 semantic versioning 发布了新版本，有信心不会破坏依赖它的程序。

如果您想了解更多关于 semantic versioning 的信息，包括如何在版本中添加除数字以外的其他信息，Semantic Versioning 网站有详细说明。Go 文档中也有一个 module version numbering 页面，解释了 Go 如何具体使用 SemVer。

有关 Go modules 的更多信息，Go 项目有一系列博客文章，详细说明了 Go 工具如何与 modules 交互和理解它们。Go 项目还在 Go Modules Reference 中提供了非常详细的技术参考。

本教程也是 How to Code in Go 系列的一部分。该系列涵盖了许多 Go 主题，从首次安装 Go 到如何使用该语言本身。