Go ベンダー ディレクトリをコミットするかどうか: 再現可能なビルドとリポジトリ サイズ?

Go 依存関係管理のためのベンダープラクティス

Go 開発では、依存関係の管理が非常に重要です。 dep ツールでは、ベンダー ディレクトリをバージョン管理にコミットすることがベスト プラクティスであるかどうかという疑問が生じます。

ベンダー ディレクトリのコミット

公式の dep FAQ がこれに対処しています。質問:

長所:

• 再現可能なビルド:名前変更、削除、履歴の上書きなどのアップストリームの変更に関係なく、一貫性のあるビルドを保証します。
• 依存関係管理の削減: クローン作成、マージ、その他のリポジトリ操作後に dep ensure を実行する必要がなくなります。

短所:

• リポジトリ サイズが大きくなる:ベンダー ディレクトリにより、リポジトリのサイズが大幅に増加する可能性があります。
• 差分競合: Gopkg.lock を変更すると、ベンダー ディレクトリが変更され、プル リクエストで差分競合が発生する可能性があります。

代替: dep ensure を手動で実行します

あるいは、ベスト プラクティスでは手動で実行することをお勧めしますリポジトリのチェックアウト後に dep ensure を実行します。このアプローチには次の利点があります。

• リポジトリ サイズが小さい: ベンダー ディレクトリがコミットされないため、リポジトリ全体のフットプリントが削減されます。
• よりクリーンな差分: PR 差分には依存関係への変更のみが含まれます。 Gopkg.lock での定義、ベンダーからのノイズの回避

結論

ベンダー ディレクトリをコミットするかどうかの決定は、特定のプロジェクトのニーズによって異なります。再現可能なビルドと効率的な依存関係管理のためには、ベンダー ディレクトリをコミットすることが有利です。ただし、リポジトリのサイズとクリーンな diff の優先順位が高い場合は、チェックアウト後に dep ensure を手動で実行する方が適切なオプションである可能性があります。

以上がGo ベンダー ディレクトリをコミットするかどうか: 再現可能なビルドとリポジトリ サイズ?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。