企业官网建设流程全解析

• 开发工具
• 包管理器

Glide 是 Go 语言的包依赖管理工具，其定位与 Cargo（Rust）、npm（Node.js）、Pip（Python）、Bundler（Ruby）等生态中的包管理器一一对应，专门用于管理$GOPATH下项目中的vendor/目录。本文以 docs/index.md 为骨架，结合本仓库源码与官方命令文档，系统讲解 Glide 的核心功能、安装方式、项目布局、glide.yaml与glide.lock双文件模型、版本约束语法以及全部常用命令，帮助你快速上手并将现有项目平滑迁移到 Glide。

Glide 是什么

Glide 是面向 Go 项目的包管理器，它解决的核心问题是：Go 1.5 引入的 vendor 机制允许每个项目在vendor/目录下存放自己的依赖副本，而 Glide 负责解析、获取、锁定并安装这些依赖。与go get直接拉取最新代码不同，Glide 通过配置文件精确记录依赖的名称、版本（或版本范围）、版本控制信息（私有仓库或类型无法自动检测时），并生成锁文件保证依赖树的可复现性。

从功能清单看，Glide 提供以下核心能力：

• 将依赖信息记录在glide.yaml文件中，包括名称、版本或版本范围，以及私有仓库或类型无法自动检测时的版本控制信息等；
• 在glide.lock文件中锁定每个包的具体 revision（提交 ID），从而支持可复现地获取整棵依赖树；
• 原生支持语义化版本（Semantic Versions）及语义化版本范围；
• 支持 Git、Bzr、HG、SVN 四种版本控制系统，与go get支持的 VCS 完全一致；
• 利用vendor/目录（即历史上所称的 "Vendor Experiment"），使不同项目可以拥有同一依赖的不同版本；
• 支持包别名（aliasing），便于处理 fork 场景；
• 可从 Godep、GPM、Gom、GB 导入既有配置。

关于当前生态的定位需要特别说明：Go 官方如今已全面转向 Go Modules 管理依赖，Glide 项目本身基本处于停更维护状态（README.md 已明确提示社区改用 Go Modules）。因此本文面向的是仍在维护基于 GOPATH + vendor 的老项目，或需要阅读、迁移历史代码仓库的开发者。

安装 Glide

官方提供了四种安装途径，覆盖脚本、发布包、系统包管理器与源码构建：

1. 一键脚本（Mac / Linux）

curl https://glide.sh/get | sh

该脚本会自动下载并安装最新的语义化版本发布包。

2. 下载版本化 Release

Glide 的发布包遵循语义化版本（Semantic Versioning），可从官方 Release 页面下载对应平台的二进制。二进制包覆盖 Mac、Linux 与 Windows。

3. 系统包管理器

• Mac 使用 Homebrew：brew install glide
• Ubuntu 12.04/14.04/15.10/16.04 使用官方 PPA：

sudo add-apt-repository ppa:masterminds/glide && sudo apt-get update sudo apt-get install glide

Ubuntu Zesty（17.04）上包名改为golang-glide。

4. 开发版快照（go get）

go get -u github.com/Masterminds/glide

注意：这种方式安装的是最新开发快照，不是发布版本。

5. 从源码构建

将本仓库克隆到$GOPATH/src/github.com/Masterminds/glide后：

• 若使用 Go 1.5，需先设置export GO15VENDOREXPERIMENT=1（Go 1.6 默认开启，Go 1.7 起始终开启且无法关闭）；
• 执行make build，得到./glide二进制，可放入$PATH（或使用make install自动安装）。

有趣的是，Glide 自身也使用 Glide 来管理自己的依赖，仓库根目录的 glide.yaml 与 glide.lock 就是活生生的自举示例。

Glide 的工作原理与项目结构

Glide 的工作流程可以概括为"扫描 → 读规则 → 拉取 → 输出"四步：

1. 扫描：Glide 扫描应用或库的源码，确定所需依赖；
2. 读规则：读取glide.yaml中的规则（版本、fork 别名等），确定每个依赖的版本与来源位置；
3. 递归解析：遇到依赖包后，继续扫描它的 import 以确定传递依赖（dependencies of dependencies）；若依赖项目自身带有glide.yaml，则优先利用其中的依赖规则；同时也会读取 Godep、GB、GOM、GPM 的配置；
4. 输出：将所有依赖导出到vendor/目录供 Go 工具链使用，并生成包含全部依赖（含传递依赖）的glide.lock文件。

一个典型的 Glide 项目结构如下：

- $GOPATH/src/myProject (你的项目) | |-- glide.yaml | |-- glide.lock | |-- main.go (你的 Go 主代码) | |-- mySubpackage (你也可以创建自己的子包) | | | |-- foo.go | |-- vendor |-- github.com | |-- Masterminds | |-- ... 等等

三个关键命令构成了日常使用的主循环：glide init初始化新项目，glide update依据扫描结果与规则重新生成依赖版本，glide install按glide.lock中锁定的版本安装（跳过扫描；若 lock 文件不存在则退化为一次 update）。

glide.yaml：项目与依赖的配置中心

glide.yaml是 Glide 的"指挥中枢"，承担两件核心工作：命名当前包、声明外部依赖。下面是一个完整示例（字段含义参考 docs/glide.yaml.md）：

package: github.com/Masterminds/glide homepage: https://glide.sh license: MIT owners: - name: Matt Butcher email: technosophos@gmail.com homepage: http://technosophos.com/ - name: Matt Farina email: matt@mattfarina.com homepage: https://www.mattfarina.com/ ignore: - appengine excludeDirs: - node_modules import: - package: gopkg.in/yaml.v2 - package: github.com/Masterminds/vcs version: ^1.2.0 repo: git@github.com:Masterminds/vcs vcs: git - package: github.com/codegangsta/cli version: f89effe81c1ece9c5b0fda359ebd9cf65f169a51 - package: github.com/Masterminds/semver version: ^1.0.0 testImport: - package: github.com/arschles/assert

顶层字段逐一说明：

• package：顶层包在GOPATH中的位置，用于防止某个 import 反向引入顶层包自身；
• homepage：项目主页地址，如http://k8s.io；
• license：SPDX 许可证标识（如MIT）或许可证文件路径，便于自动化工具与使用者识别；
• owners：一个或多个项目所有者（个人或组织），可用于安全问题的定向通知而不必公开提交 bug；
• ignore：需要 Glide 忽略的包名列表（注意是包名而非目录）；
• excludeDirs：本地代码库中需要排除在依赖扫描之外的目录列表；
• import：要导入的包列表，每项可包含：
  • package：包名，唯一必填项。命名规则与go工具一致：映射到 VCS 远程位置的包名以.git、.bzr、.hg、.svn结尾（如example.com/foo/pkg.git/subpkg）；GitHub、BitBucket、Launchpad、IBM Bluemix Services 与 Google Source 上的 Go 包是特例，无需 VCS 扩展名；
  • version：语义化版本、版本范围、分支、标签或提交 ID，详见 docs/versions.md；
  • repo：当包名并非仓库地址、或属于私有仓库时在此指定实际仓库地址。包会从该 repo 检出并放到package指定的位置，这正是 fork 别名能力的来源（package与repo可以完全不同）；
  • vcs：指定 VCS 类型（git、hg、bzr、svn），仅在名称无法自动检测类型时需要。例如以.git结尾或位于 GitHub 的仓库可自动识别为 Git，而 Bitbucket 上的仓库会通过 API 探测类型；
  • subpackages：仓库中被实际使用的子包记录（而非仓库内全部包）；
  • os：操作系统过滤列表。设置后 Glide 会比较当前运行 OS 与列表，匹配才拉取该依赖；未设置则跳过过滤。名称与构建标记及GOOS环境变量的取值一致；
  • arch：架构过滤列表，逻辑同os，取值与GOARCH一致。
• testImport：测试专用的依赖包列表，不在import中重复出现，每项的字段与import完全相同。

版本写法提示：version要么是 VCS 相关的取值（任何能 checkout 的东西，如 Git 的分支、标签、哈希），要么是能被github.com/Masterminds/semver包解析的语义化版本约束。另外建议使用基础包名而非子包名导入，例如用github.com/kylelemons/go-gypsy而不是github.com/kylelemons/go-gypsy/yaml。

源码中的字段落地

在源码 cfg/config.go 中，Config结构体通过 YAML tag 与上述字段一一对应：Name（package）、Description、Home（homepage）、License、Owners、Ignore、Exclude（excludeDirs）、Imports（import）、DevImports（testImport）。每个依赖则对应 Dependency 结构体：Name（package）、Reference（version）、Repository（repo）、VcsType（vcs）、Subpackages、Arch、Os。该结构体还实现了UnmarshalYAML/MarshalYAML钩子（cfg/config.go），负责将旧格式的ref字段映射为version、过滤非法 VCS 类型、将子包名规范化为根包名等兼容性处理，说明 Glide 对历史配置有相当好的宽容度。

仓库自身的 glide.yaml 就是一个可复制的真实示例：依赖gopkg.in/yaml.v2（无版本约束）、github.com/Masterminds/vcs（^1.13.1）、github.com/codegangsta/cli（^1.16.0）、github.com/Masterminds/semver（^1.4.0）以及github.com/mitchellh/go-homedir（无版本约束）。

版本与范围：语义化版本的完整语法

Glide 全面支持语义化版本（SemVer）、SemVer 范围、分支、标签与提交 ID。版本语法的完整说明见 docs/versions.md，以下是各语法形态：

基本范围运算符

简单范围形如> 1.2.3，表示取1.2.3之后的最新版本。支持以下运算符：

运算符可以组合：,是"与"，||是"或"，||会让两侧的"与"组分别参与判定。例如">= 1.2, < 3.0.0 || >= 4.2.3"。

连字符范围（Hyphen Ranges）

• 1.2 - 1.4.5等价于>= 1.2, <= 1.4.5
• 2.3.4 - 4.5等价于>= 2.3.4, <= 4.5

通配符比较

x、X、*均可作为通配符，适用于所有比较运算符；用在=上时退化为补丁级别比较（见 Tilde）。例如：

• 1.2.x等价于>= 1.2.0, < 1.3.0
• >= 1.2.x等价于>= 1.2.0
• <= 2.x等价于< 3
• *等价于>= 0.0.0

Tilde 范围（补丁级）

~用于补丁级范围；当指定了 minor 版本时限制补丁级变化，当缺少 minor 号时则限制 major 级变化：

• ~1.2.3等价于>= 1.2.3, < 1.3.0
• ~1等价于>= 1, < 2
• ~2.3等价于>= 2.3, < 2.4
• ~1.2.x等价于>= 1.2.0, < 1.3.0
• ~1.x等价于>= 1, < 2

Caret 范围（Major 级）

^用于 major 级范围，适合 API 版本约束——major 变化通常意味着 API 破坏性变更：

• ^1.2.3等价于>= 1.2.3, < 2.0.0
• ^1.2.x等价于>= 1.2.0, < 2.0.0
• ^2.3等价于>= 2.3, < 3
• ^2.x等价于>= 2.0.0, < 3

glide.lock：可复现安装的关键

与glide.yaml记录"规则"不同，glide.lock 记录的是完整依赖树与每个包当前使用的 revision（提交 ID）。它的价值在于：

• 并发安装：由于完整依赖树已知，glide install可以同时为多个依赖安装并设置正确的 revision，实现快速、可复现的安装；
• 审计与排障：lock 文件保留了超出当前代码库需要的完整依赖树记录与 revision 信息，可用于审计、或排查问题期间定位依赖树发生了什么变化。

lock 文件不应手工编辑——只要你会读glide.yaml，就能大致读懂glide.lock（docs/glide.lock.md）。本仓库根目录的 glide.lock 展示其真实格式：顶部是hash（依赖树哈希）与updated时间戳，接着是imports列表，每个条目包含name与version（指向具体的 commit ID），以及空的testImports。

典型使用链路：glide update在glide.yaml中声明^1.2.3这类范围时，会在glide.lock中固定到具体 commit ID；glide install则直接读取 lock 文件安装这些固定版本，从而保证团队与 CI 环境的依赖完全一致。

核心命令全览

Glide 的命令体系围绕"初始化、增删依赖、更新、安装、检查"设计，完整文档见 docs/commands.md，对应实现位于 action/ 目录。

glide create（别名 init）——初始化工作区

创建glide.yaml并尝试猜测包与版本：若项目已使用 Godep，则采用其指定版本；Glide 会扫描代码库，无论依赖是否由其他包管理器声明，都能识别出正在使用的 import。

$ glide create [INFO] Generating a YAML configuration file and guessing the dependencies [INFO] Attempting to import from other package managers (use --skip-import to skip) [INFO] Scanning code to look for dependencies [INFO] --> Found reference to github.com/Masterminds/semver [INFO] --> Found reference to github.com/Masterminds/vcs [INFO] --> Found reference to github.com/codegangsta/cli [INFO] --> Found reference to gopkg.in/yaml.v2 [INFO] Writing configuration file (glide.yaml) [INFO] Would you like Glide to help you find ways to improve your glide.yaml configuration? [INFO] If you want to revisit this step you can use the config-wizard command at any time. [INFO] Yes (Y) or No (N)? n [INFO] You can now edit the glide.yaml file. Consider: [INFO] --> Using versions and ranges. See https://glide.sh/docs/versions/ [INFO] --> Adding additional metadata. See https://glide.sh/docs/glide.yaml/ [INFO] --> Running the config-wizard command to improve the versions in your configuration

使用--skip-import可跳过从其他包管理器导入的尝试。

glide config-wizard——交互式版本向导

运行一个向导，扫描依赖并获取其信息，交互式地给出建议：例如发现依赖使用语义化版本，帮助挑选合适的版本范围。可随时重新运行（对应实现见 action/config_wizard.go）。

glide get [package name]——获取并登记依赖

将一个或多个包下载到vendor/目录并写入glide.yaml：

$ glide get github.com/Masterminds/cookoo

get会内部解析该包的依赖，包括读取其 Godep、GPM、Gom、GB 配置文件。还支持把版本或范围与包名一起传入，用锚点#分隔：

$ glide get github.com/Masterminds/cookoo#^1.2.3

若未指定版本或范围、且依赖使用了语义化版本，Glide 会交互式询问是否采用。

glide update（别名 up）——更新整棵依赖树

下载或更新glide.yaml中列出的全部库到vendor/，并递归遍历依赖包拉取所需内容、读取其配置：

$ glide up

递归过程中会查找其他由 Glide、Godep、gb、gom、GPM 管理的项目，发现即按需安装。同时创建或更新glide.lock，把依赖固定到具体版本：例如glide.yaml中声明范围为^1.2.3，则 lock 文件会记录具体 commit ID，为glide install的可复现安装提供基础。使用-v标志可移除拉取包中嵌套的vendor/目录。

glide install——按锁文件安装

从glide.lock安装 commit ID 级别的精确版本：

$ glide install

• 若 lock 文件与glide.yaml不一致（例如配置有变更），会给出警告；重新运行glide up即可重建 lock 文件；
• 若不存在 lock 文件，install会自动执行一次 update 并生成 lock 文件。

glide novendor（别名 nv）——跳过 vendor 测试

go test ./...会遍历包括vendor在内的所有子目录，而测试自己的应用时往往不希望跑依赖及其传递依赖的全部测试。novendor列出除vendor外的所有目录：

$ go test $(glide novendor)

glide name——输出包名

脚本化场景下需要知道当前包名时使用，返回glide.yaml中记录的包名。

glide tree——导入树可视化（已废弃）

展示导入树（不含标准库），由于 vendoring 使同一包可能存在于多个位置，tree会同时打印每个包的所在路径。该命令已废弃，将在未来版本移除（见 README.md 与 action/tree.go）。

glide list——列出全部导入包

按字母序展示项目导入的全部包：

$ glide list INSTALLED packages: vendor/github.com/Masterminds/cookoo vendor/github.com/Masterminds/cookoo/fmt vendor/github.com/Masterminds/cookoo/io vendor/github.com/Masterminds/cookoo/web vendor/github.com/Masterminds/semver vendor/github.com/Masterminds/vcs vendor/github.com/codegangsta/cli vendor/gopkg.in/yaml.v2

glide help 与 glide --version

$ glide help # 打印帮助 $ glide --version # 打印版本并退出 glide version 0.12.0

glide mirror——仓库镜像管理

镜像允许把某个仓库地址替换为另一个镜像地址，常用于 CI 缓存或本地开发依赖：

glide mirror set [original] [replacement] glide mirror set [original] [replacement] --vcs [type]

例如：

glide mirror set https://github.com/example/foo https://git.example.com/example/foo.git glide mirror set https://github.com/example/foo file:///path/to/local/repo --vcs git

移除与列出镜像：

glide mirror remove [original]

镜像配置存放在GLIDE_HOME目录下的mirrors.yaml文件中（详见 docs/mirrors.md 与 mirrors/ 目录）。在源码层面，Dependency.Remote()方法（cfg/config.go）正是先检查镜像映射、再决定实际拉取地址的枢纽。

支持的版本控制系统

Glide 支持 Git、SVN、Mercurial（Hg）与 Bzr 四种 VCS，与go get的支持范围一致，具体交互通过github.com/Masterminds/vcs包完成（见 repo/vcs.go）。其中 bzr 与 hg 属于"进行中"的支持状态，可能需要额外调优。

从其他包管理器导入配置

导入 GPM、Godep、gom、gb 配置分为两个层面：

1. 传递安装：当你 import 的某个包自身带有 GPM/Godep/gom/gb 配置时，Glide 会递归地自动安装其依赖；
2. 显式导入：使用glide import命令生成glide.yaml，例如glide import godep会检测项目的 Godep 配置并生成配置文件。

导入操作会合并你现有的glide.yaml与对应管理器发现的依赖，然后输出结果，不会覆盖原文件。写入文件示例：

$ glide import godep -f glide.yaml

常见问题（FAQ）

Q：Go 本身没有子包概念，为什么 Glide 要有 subpackages？

Go 中每个目录就是一个包，单仓库多包时没问题；但多个包分布在不同的 VCS 位置时情况复杂了。一个包含多个包的集合项目，应使用同一份信息（含版本）来管理，通过 subpackages 分组，Glide 就能统一管理相关包的信息。

Q：bzr（或 hg）行为不符合预期？

这两个 VCS 的支持属于进行中状态，可能还需调优。可关注github.com/Masterminds/vcs包及其测试（如 repo/vcs.go）。

Q：应该把vendor/提交进版本控制吗？

取决于你。它不是必需的，但入库可能带来额外工作量和 VCS 空间的显著膨胀，也可能引发一些难以预料的错误。

Q：Glide 能按 OS 或 Arch 拉取包吗？

可以。使用依赖项的os与arch字段即可指定拉取的目标平台，例如以下配置只在 64 位 Darwin/OSX 系统上拉取：

- package: some/package os: - darwin arch: - amd64

其他 OS/架构下该包不会被拉取。对应源码中 Dependency.Os/Arch 过滤 在扫描阶段即参与判定（dependency/scan.go）。

进一步阅读

• docs/commands.md：全部命令的详细行为
• docs/glide.yaml.md：glide.yaml字段精讲
• docs/versions.md：语义化版本与范围语法
• docs/glide.lock.md：锁文件设计说明
• docs/importing.md 与 action/import_godep.go、action/import_gpm.go、action/import_gom.go、action/import_gb.go：从其他包管理器导入的实现
• docs/vendor.md 与 docs/getting-started.md：vendor 机制与快速上手
• glide.yaml 与 glide.lock：仓库自举使用的真实示例

最后提醒：若你正在启动全新 Go 项目，请优先使用 Go 官方 Modules；Glide 更适合用于理解与维护 2015—2019 年间基于 GOPATH + vendor 的存量项目，其glide.yaml/glide.lock双文件设计与 SemVer 范围语法，至今仍是理解 Go 依赖管理演进史的重要参考资料。

• 开发工具
• 包管理器