git - composer.lockをバージョン管理にコミットする必要がありますか？

Question

composer.lockリポジトリのあるアプリケーションで使用するのと少し混乱しています。

.gitignore composer.lock多くの人がリポジトリからはいけないと言っているのを見ました。

開発環境でライブラリを更新すると、新しいライブラリが作成されますが、composer.lock本番環境に更新することはできません。

このファイルで競合が発生しませんか？

Answer 1

ライブラリを更新する場合は、ロックファイルもコミットする必要があります。基本的に、使用しているライブラリの特定のバージョンにプロジェクトがロックされていることを示しています。

変更をコミットし、誰かがコードをプルして依存関係を更新した場合、ロックファイルは変更されていないはずです。変更されている場合は、何かの新しいバージョンがあることを意味します。

リポジトリにあることで、各開発者が同じバージョンを使用していることが保証されます。

Answer 2

アプリケーション/プロジェクトの場合: もちろんそうです。

composer documentationはこれについて述べています（強調して）：

アプリケーションの composer.lock を (composer.json と共に) バージョン管理にコミットします。

@mezaが言ったように：ロックファイルをコミットして、あなたとあなたの共同作業者が同じバージョンのセットで作業し、「しかし、私のコンピューターでは機能しました」などの発言を防ぐ必要があります。;-)

図書館の場合：おそらくそうではありません。

コンポーザーのドキュメントには、この問題について次のように記載されています。

注: ライブラリの場合、ロック ファイルをコミットすることは必ずしも推奨されません (...)

そしてここに述べます：

ライブラリについては、必要に応じて composer.lock ファイルをコミットできます。これにより、チームは常に同じ依存関係バージョンに対してテストを行うことができます。ただし、このロック ファイルは、それに依存する他のプロジェクトには影響しません。メインプロジェクトにのみ影響します。

ライブラリについては、@ Josh Johnsonの回答に同意します。

Answer 3

1. 依存関係を本番環境で直接更新しないでください。
2. composer.lockファイルをバージョン管理する必要があります。
3. 実際の依存関係をバージョン管理するべきではありません。

1.依存関係を Productionで直接更新しないでください。これがコードの安定性にどのように影響するかわからないためです。新しい依存関係でバグが導入される可能性があり、コードの動作が変更されて自分自身に影響を与える可能性があります。他の依存関係と互換性がない可能性があります。適切な QA と回帰テストなどに従って、開発環境でこれを行う必要があります。 .

2. composer.lockファイルをバージョン管理する必要があります。これは、コードの現在の状態を複製できるようにする依存関係および依存関係の依存関係に関する情報を保存するためです。すべてのテストと開発は特定のコードに対して行われているため、これは重要です。所有しているコードの実際のバージョンを気にしないことは、コードの変更をアプリケーションにアップロードし、それらをテストしないことに似ています。依存関係のバージョンをアップグレードする場合、これは自発的に行う必要があり、すべてが引き続き機能するように必要な注意を払う必要があります。以前のリリース バージョンに戻すために 1 ～ 2 時間の稼働時間を失うと、多額の費用がかかる可能性があります。

composer.lockを必要としないことについて目にする議論の 1 つは、composer.jsonファイルで必要な正確なバージョンを設定できるということです。このようにして、誰かが を実行するたびに、composer installそれらを同じようにインストールします。コード。依存関係には独自の依存関係があり、それらの構成は、サブバージョンまたはバージョン全体の更新を許可する形式で指定されている可能性があるため、これは正しくありません。

これは、 composer.jsonで Laravel 4.1.31 が必要であることを指定した場合でも、そのcomposer.jsonファイルの Laravel には、Symfony イベントディスパッチャーとして必要な独自の依存関係がある可能性があることを意味します: 2.*. この種の構成では、Symfony event-dispatcher 2.4.1 を使用する Laravel 4.1.31 になる可能性があり、チームの他の誰かが event-dispatcher 2.6.5 を使用する Laravel 4.1.31 を使用する可能性があります。 composerインストールを最後に実行したのは.

したがって、バージョン システムにcomposer.lockファイルがあると、このサブ依存関係の正確なバージョンが保存されるため、あなたとチームメイトが composer インストールを行う場合 (これは、composer に基づいて依存関係をインストールする方法です。 lock ) 両方とも同じバージョンを取得します。

更新したい場合はどうしますか？次に、開発環境で run:composer updateを実行すると、新しいcomposer.lockファイルが生成され (何か新しいものがある場合)、それをテストした後、QA テストと回帰テストが行​​われます。安全にアップグレードできるため、新しいcomposer.lockをダウンロードするように他の全員にプッシュできます。

3.意味がないので、実際の依存関係をバージョン管理するべきではありません。composer.lockを使用すると、依存関係の正確なバージョンをインストールでき、それらをコミットする必要はありません。依存関係の 10000 ファイルを更新することになっていないのに、なぜそれらをレポに追加するのでしょうか。これのいずれかを変更する必要がある場合は、それをフォークして、そこで変更を加える必要があります。また、ビルドまたはリリースのたびに実際の依存関係を取得する必要があることを心配している場合、composer にはこの問題を軽減するさまざまな方法、キャッシュ、zip ファイルなどがあります。

Answer 4

次に、プロジェクトにコミットするcomposer.jsonと、チームの他の全員が composer install を実行して、プロジェクトの依存関係をインストールできます。

ロック ファイルのポイントは、インストールされている正確なバージョンを記録して、再インストールできるようにすることです。これは、バージョン仕様が 1.* で、同僚が composer update を実行して 1.2.4 をインストールし、composer.lock ファイルをコミットした場合、composer をインストールすると、1.2.4 も取得されることを意味します。 1.3.0 がリリースされている場合。これにより、プロジェクトで作業している全員が正確に同じバージョンを使用できるようになります。

これは、composer のインストールが最後に行われた後に何かがコミットされた場合、ロック ファイルがなければ、新しいサードパーティ コードがプルダウンされることを意味します。

繰り返しますが、コードの破損が心配な場合、これは問題です。これが、Composer が composer.lock ファイルを中心として考えることが重要である理由の 1 つです。

出典: Composer: It's All About the Lock File .

---

アプリケーションの composer.lock を (composer.json と共に) バージョン管理にコミットします。インストール コマンドはロック ファイルが存在するかどうかをチェックし、存在する場合はそこに指定されたバージョンをダウンロードするため、これは重要です (composer.json の内容に関係なく)。これは、プロジェクトをセットアップする人は誰でも、まったく同じバージョンの依存関係をダウンロードすることを意味します。CI サーバー、運用マシン、チーム内の他の開発者など、すべての人が同じ依存関係で実行されるため、展開の一部にのみ影響するバグの可能性が軽減されます。単独で開発した場合でも、6 か月後にプロジェクトを再インストールすると、依存関係がその後多くの新しいバージョンをリリースしたとしても、インストールされた依存関係がまだ機能していると確信できます。

出典: Composer - 基本的な使い方.