我在 go1.12 上使用 go 模塊來處理我的 Go 依賴項。將目錄提交vendor/到版本控制是否是最佳做法？這與提交“供應商”目錄是否是最佳實踐有關？在使用的情況下會問這個問題dep。使用dep，提交vendor/是獲得真正可重復構建的唯一方法。go 模塊呢？
2 回答
慕桂英4014372
TA貢獻1871條經(jīng)驗 獲得超13個贊
除非您需要修改供應商的軟件包，否則您不應該這樣做。Go 模塊已經(jīng)為您提供了可重復的構建，因為該go.mod文件記錄了您的依賴項的確切版本和提交哈希，該go工具將尊重并遵循這些。
該vendor目錄可以通過運行go mod vendor命令重新創(chuàng)建，并且默認情況下它甚至會被忽略，go build除非您要求它與-mod=vendor標志一起使用。
慕慕森
TA貢獻1856條經(jīng)驗 獲得超17個贊
我想給出一些支持提交的論據(jù)vendor，go.mod和go.sum。
我同意接受的答案的論點，即它在技術上是不必要的并且會使回購膨脹。
但這里有一個反論點列表：
構建項目不依賴于 Github/Gitlab/... 或 Go 代理服務器上可用的某些代碼。開源項目可能會因為審查、作者激勵、許可變更或其他一些我目前無法想到的原因而消失，這確實發(fā)生在 JavaScript 包管理器 npm 上，并且破壞了許多項目。不在您的倉庫中，不在您的代碼中。
我們可能使用了內部或第 3 方 Go 模塊（私有），它們也可能消失或無法訪問，但如果它們在供應商中提交，它們就是我們項目的一部分。沒有什么意外中斷。
私有 Go 模塊可能不遵循語義版本控制，這意味著 Go 工具在動態(tài)獲取它們時將依賴最新的提交哈希?；刭彋v史可能會被重寫（例如 rebase），您、同事或您的 CI 工作最終可能會為他們使用的依賴項編寫不同的代碼。
提交供應商可以改善您的代碼審查過程。通常，我們總是在單獨的提交中提交依賴項更改，因此如果您好奇，可以輕松查看它們。
這是一個與膨脹回購有關的有趣觀察。如果我進行代碼審查并且團隊成員包含了一個包含 300 個文件的新依賴項（或更新了一個包含 300 個文件更改的依賴項），我會非常好奇地深入研究它并開始討論代碼質量，這種更改的必要性或替代 Go 模塊。這實際上可能會導致您的二進制文件大小和整體復雜性降低。
如果我在新的合并請求中只看到一個新行，go.mod我什至不會考慮它。
執(zhí)行編譯和構建步驟的 CI/CD 作業(yè)無需在每次執(zhí)行 CI 作業(yè)時浪費時間和網(wǎng)絡來下載依賴項。所有需要的依賴項都是本地的并且存在（
go build -mod vendor）
這些都在我頭上，如果我記得還有什么，我會在這里添加。
- 2 回答
- 0 關注
- 169 瀏覽
添加回答
舉報
0/150
提交
取消