因此它默认取的是主分支最新一次 commit 的 commit 时间和 commithash，也就是 20200220041913-e066a990ce6f，属于第二种情况。

有发布 tags

在项目有发布 tags 的情况下，还存在着多种模式，也就是只有单个模块和多个模块，我们统一以多个模块来进行展示，因为多个模块的情况下就已经包含了单个模块的使用了，如下图：

在这个项目中，我们一共打了两个tag，分别是：v0.0.1 和 module/tour/v0.0.1。这时候你可能会奇怪，为什么要打 module/tour/v0.0.1 这么“奇怪”的tag，这有什么用意吗？

其实是 Go modules 在同一个项目下多个模块的tag表现方式，其主要目录结构为：

mquote├── go.mod├── module│   └── tour│       ├── go.mod│       └── tour.go└── quote.go

可以看到在 mquote 这个项目的根目录有一个 go.mod 文件，而在 module/tour 目录下也有一个 go.mod 文件，其模块导入和版本信息的对应关系如下：

导入主模块和子模块

结合上述内容，拉取主模块的话，还是照旧执行如下命令：

$ go get github.com/eddycjy/mquote@v0.0.1go: finding github.com/eddycjy/mquote v0.0.1go: downloading github.com/eddycjy/mquote v0.0.1go: extracting github.com/eddycjy/mquote v0.0.1

如果是想拉取子模块，执行如下命令：

$ go get github.com/eddycjy/mquote/module/tour@v0.0.1go: finding github.com/eddycjy/mquote/module v0.0.1go: finding github.com/eddycjy/mquote/module/tour v0.0.1go: downloading github.com/eddycjy/mquote/module/tour v0.0.1go: extracting github.com/eddycjy/mquote/module/tour v0.0.1

我们将主模块和子模块的拉取进行对比，你会发现子模块的拉取会多出一步，它会先发现 github.com/eddycjy/mquote/module，再继续推算，最终拉取到 module/tour。

Go Modules 的导入路径说明

不同版本的导入路径

在前面的模块拉取和引用中，你会发现我们的模块导入路径就是 github.com/eddycjy/mquote 和  github.com/eddycjy/mquote/module/tour，似乎并没有什么特殊的。

其实不然，实际上 Go modules 在主版本号为 v0 和 v1 的情况下省略了版本号，而在主版本号为v2及以上则需要明确指定出主版本号，否则会出现冲突，其tag与模块导入路径的大致对应关系如下：

简单来讲，就是主版本号为 v0 和 v1 时，不需要在模块导入路径包含主版本的信息，而在 v1 版本以后，也就是 v2 起，必须要在模块的导入路径末尾加上主版本号，引用时就需要调整为如下格式：

import (    "github.com/eddycjy/mquote/v2/example")

另外忽略主版本号 v0 和 v1 是强制性的（不是可选项），因此每个软件包只有一个明确且规范的导入路径。

为什么忽略 v0 和 v1 的主版本号

1. 导入路径中忽略 v1 版本的原因是：考虑到许多开发人员创建一旦到达 v1 版本便永不改变的软件包，这是官方所鼓励的，不认为所有这些开发人员在无意发布 v2 版时都应被迫拥有明确的 v1 版本尾缀，这将导致 v1 版本变成“噪音”且无意义。

2. 导入路径中忽略了 v0 版本的原因是：根据语义化版本规范，v0的这些版本完全没有兼容性保证。需要一个显式的 v0 版本的标识对确保兼容性没有多大帮助。

Go Modules 的语义化版本控制

我们不断地在 Go Modules 的使用中提到版本号，其实质上被称为“语义化版本”，假设我们的版本号是 v1.2.3，如下：