我開始接觸 Go，雖然我理解并欣賞Go 所基于的簡單原則，但我想了解在他們的依賴獲取工具中放棄內置包版本控制方法背后的基本原理go get和該import聲明。如果我理解正確，go get并import從中獲取包HEAD，他們將無法引用分支或標簽。雖然有像gopkg.in這樣的工具可以繞過這個限制，但官方工具鏈：強制開發人員為其產品的主要（破壞性）版本創建單獨的存儲庫。它不允許消費者在小版本或微型版本之間降級，以防在較新的版本中發現錯誤。說實話，事情并沒有那么容易，因為包版本控制需要一種策略來處理沖突的傳遞依賴關系，例如X依賴A和B，每個依賴于不同版本的C.從 Java 背景來看，這個限制確實帶來了一些風險和問題，其中包括：產品/包的演變和 3rd 方 deps 公共 API 的損壞是不可避免的，因此版本控制必須是工具鏈中的一等公民恕我直言。在Git的回購每版的政策是非常低效的：包的整體 Git 歷史丟失或分散在存儲庫中（版本、向后移植等之間的合并）與傳遞依賴的沖突可能仍然會發生，并且不會被檢測到，因為語言和工具鏈首先強加了任何允許檢測的語義。鑒于以下情況，企業采用可能會受到阻礙，開發團隊可能會回避該語言：總是拖延HEAD意味著他們無法控制或凍結他們的第 3 方部門，從而導致可能無法預測的最終產品?？赡苋狈θ肆肀３炙麄兊漠a品不斷更新和與上游的測試HEAD（并非世界上的每家公司都是谷歌:)）。雖然我確實理解后一種風險可以——而且必須——通過持續集成來減輕，但它并沒有解決問題的根本根源。我缺少什么信息？在人力有限的企業中部署 Go 時，如何處理包上游變化？