Go 1.5 中的包版本管理

在IT行业这个发展更新速度很快的行业，只有不停止的学习，才不会被行业所淘汰。如果你是Golang学习者，那么本文《Go 1.5 中的包版本管理》就很适合你！本篇内容主要包括Go 1.5 中的包版本管理，希望对大家的知识积累有所帮助，助力实战开发！

问题内容

我开始接触 Go，虽然我理解并欣赏 Go 所基于的 简单性 原则，但我想了解在他们的依赖项获取工具中放弃 内置包版本控制方法go get的基本原理和import声明。

如果我理解正确，go get并import从中获取包HEAD，他们将无法引用分支或标签。虽然有像gopkg.in这样的工具可以绕过这个限制，但官方工具链：

1. 强制开发人员为其产品的主要（破坏性）版本创建单独的存储库。
2. 它不允许消费者在次要版本或微型版本之间降级，以防在较新版本中发现错误。

说实话，事情并不那么容易，因为包版本控制需要一种策略来处理冲突的传递依赖关系，例如X依赖A和B，每个依赖于不同版本的C.

由于具有 Java 背景，这种限制似乎确实带来了一些风险和问题，其中包括：

1. 产品/包的演变和第三方部门公共 API 的破坏是不可避免的，因此版本控制必须是工具链中的一等公民恕我直言。

2. Git-repo-per-version 策略非常低效：

• 包的整体 Git 历史丢失或分散在存储库中（版本之间的合并、反向移植等）
• 与传递依赖的冲突可能仍然会发生，并且不会被发现，因为语言和工具链都会强加任何语义以首先允许检测。

3. 企业采用可能会受到阻碍，开发团队可能会回避该语言，因为：

• 总是拖入HEAD意味着他们无法控制或冻结他们的第 3 方部门，从而导致潜在的不可预测的最终产品。
• 可能缺乏人力来保持他们的产品不断更新并与上游的测试HEAD（并非世界上每家公司都是谷歌:)）。

虽然我确实理解后一种风险可能是“并且必须”通过持续集成来减轻，但它并不能解决问题的根本根源。

我缺少什么信息？在人力有限的企业部署 Go 时如何处理包上游变更？

正确答案

它正在通过作为 Go 1.5 的一部分作为实验性功能的vendoring来解决，如果 go 命令在其环境中运行，它可以启用GO15VENDOREXPERIMENT=1，并且将成为 Go 1.6 中的“完整”功能。另请参阅供应商目录。

可以在[此处](https://groups.google.com/forum/#!msg/golang- dev/74zjMON9glU/4lWCRDCRZg0J)找到导致 Go 1.5 Vedor Experiment 的原始讨论。

vendoring 的本质是创建一个名为 的文件夹vendor，并放置代码所依赖的包的确切版本。文件夹内的vendor代码只能由以 的父级为根的目录树中的代码导入vendor，并且您可以vendor使用导入路径vendor从workspace/src文件夹导入包（即，使用省略前缀的导入路径）并包括供应商元素）。

例子：

/home/user/goworkspace/
    src/
        mymath/
            mymath.go
            vendor/
                github.com/somebob/math
                    math.go

在此示例中，是package (from )github.com/somebob/math使用的外部包。如果像这样导入它，则可以使用它：mymath``mymath.go``mymath.go

import "github.com/somebob/math"

（而不是那样import mymath/vendor/github.com/somebob/math会不好。）

今天带大家了解了golang的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~