import "github.com/RichardKnop/somelibrary"
这将尝试寻找一个分支，基于您的Go版本和默认为master如果我理解正确。
所以没有办法导入一个特定版本的依赖，例如：
import "github.com/RichardKnop/somelibrary#v1.4.8"
那么在Go中管理依赖关系的最佳实践是什么？
我可以看到两种方法。
I.版本模块
是为主要版本创建具有突变的新模块吗？
例如，我的Go库可以定义模块v1和v2，那么你可以这样做：
import "github.com/RichardKnop/somelibrary/v1"
要么：
import "github.com/RichardKnop/somelibrary/v2"
基于你所需要的。对v1或v2所做的任何更改都不需要破坏任何API或工作功能。
II。分叉
这将使您完全控制Go代码所需的外部依赖项的版本。
例如，您可以将github.com/RichardKnop/somelibrary fork到您自己的GitHub帐户中，然后在您的代码中执行：
import "github.com/ForkingUser/somelibrary"
然后你必须fork所有外部依赖，这似乎有点凌乱。但它会给你完全控制版本。你可以保持你的分叉的版本，你知道是在使用你的代码，只有更新叉，一旦你检查了新版本的依赖关系不会破坏任何东西。
想法？
见c/10923/：
When
GO15VENDOREXPERIMENT=1is in the environment,this CL changes the resolution of import paths according to the Go 1.5 vendor proposal:
- If there is a source directory
d/vendor,then,when compiling a source file within the subtree rooted atd,import "p"is interpreted asimport "d/vendor/p"if that exists.- When there are multiple possible resolutions,the most specific (longest) path wins.
- The short form must always be used: no import path can contain “
/vendor/” explicitly.- Import comments are ignored in vendored packages.
更新2016年1月：Go 1.6将使默认。
详细the article “MOST GO TOOLS NOW WORK WITH GO15VENDOREXPERIMENT”：
1.6 brings support for
/vendor/to most tools (like the oracle) out of the Box; use the Beta to rebuild them.
> issue 12278已解决。
>还有一个issue with goimports，还有一个CL是can be cherry-picked。
