Go プロジェクトのベンダー ディレクトリをバージョン管理にコミットする必要がありますか?

Go 開発におけるベンダー ディレクトリのバージョン管理

dep ツールを使用して Go の依存関係を管理する場合、開発者はコミットするかどうかの決定に直面しますベンダー ディレクトリをバージョン管理に追加するか、リポジトリをチェックアウトした後に dep ensure を実行します。

この問題に関するガイダンスを提供するには、 dep ツールの FAQ では、次の質問に明確に対処しています:

ベンダー ディレクトリをコミットする必要がありますか?

この FAQ では、最終的には開発者が決定することを認めていますが、両方の点について概説しています。各アプローチの長所と短所:

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

• 長所:

  • アップストリームの変更や履歴の書き換えから保護することで、真に再現可能なビルドを保証します。
  • go get を含むほとんどの操作後の dep ensure の必要性を排除します。

• 短所:

  • リポジトリのサイズが増加し、かなり大きくなる可能性があります。
  • Gopkg.lock が変更されると、ベンダー ディレクトリの変更が PR diff に追加されますが、 GitHub ではベンダー ファイルはデフォルトで非表示になっています。

チェック後に dep ensure を実行する利点:

• 長所:

  • リポジトリ サイズを小さく維持します。
  • ベンダーを自動的に更新します。リポジトリのチェックアウト、確保一貫性。

• 短所:

  • リポジトリをチェックアウトした後に追加のビルド手順が必要です。
  • ベンダー ディレクトリの変更が発生する可能性があり、 diffs.

最終的に、ベスト プラクティスは特定のプロジェクト要件によって異なります。再現性を優先し、不必要なビルド手順を避ける開発者は、ベンダー ディレクトリをコミットすることを選択する場合があります。ただし、リポジトリのサイズを懸念しており、依存関係の同期を自動化したい場合は、チェックアウト後に dep ensure を実行することを好む場合があります。

以上がGo プロジェクトのベンダー ディレクトリをバージョン管理にコミットする必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。