我得到我的手一起去脏，虽然我理解和欣赏的原理 简单 说离开是在建，我想把握原理背后放弃一个 内置的封装版本的方法 在他们的依赖，获取工具go get和该import声明。

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

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

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

从Java的背景来看，这种限制确实带来了一些风险和问题，其中包括：

1. 产品/包装的发展以及第三方部门公共API的破坏是不可避免的，因此版本控制必须是IMHO工具链中的一等公民。

2. 在 Git的回购每版 的政策是非常低效的：

   • 软件包的整体Git历史记录丢失或分散在存储库中（版本，反向端口等之间的合并）
   • 与传递依赖项的冲突仍然可能发生，并且由于语言或工具链强加了任何允许首先进行检测的语义，因此无法检测到。

   • 鉴于以下原因，企业采用可能会受到阻碍，并且开发团队可能会回避使用该语言：

   • 始终拖入HEAD意味着他们无法控制或冻结他们的第三方部门，从而导致潜在的不可预测的最终产品。

   • 可能缺乏人力来保持其产品不断更新并在上游进行测试HEAD（世界上并非每个公司都是Google :)）。

虽然我确实知道，通过持续集成可以（并且必须）减轻后一种风险，但它并不能解决问题的根本原因。

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