私はcomposerをインストールし、「composerinstall」を介していくつかのパッケージを追加しました。それらは「my_project\vendor」パスの下にインストールされましたが、一部のパッケージはgitを使用して複製されたため、「my_project」をコミットすると、それらの複製されたパッケージは無視されました。
問題は、他の開発者が「my_project」のクローンを作成しているときに、無視されたパッケージが欠落していることです。他の開発者が私からパッケージを取得できるように、パッケージを「my_project」に自動的に追加する方法はありますか？
これはサブモジュールを使用して行う必要があると思いますが、composerからのすべての新しいパッケージをサブモジュールとしてプロジェクトに自動的に追加する方法がわかりません。
理想的には、.gitignoreにvendor /を追加するだけで、プロジェクトのすべての開発者がcomposer installを実行して、ベンダーをセットアップに参加させることができます。
詳細については、ベンダーのコミットに関するFAQエントリを参照してください。
序文：ジョルディ-私は作曲家が大好きで、素晴らしい仕事を続けています。これのいずれかを間違えた場合は、私に知らせてください。ワークフローを更新し、投稿を編集します：D
残念ながら、これはあなたが誰に尋ねるかによっては「一般的な推奨事項」ではなく、開発者のみの視点です。また、作曲家のFAQで規定されている方法を使用する際の注意点には、ここで説明できるよりも多くの考慮事項があります。それで、他の人の考慮のためにいくつかの主要なポイントを残しておきます。
@Seldaek自身の入場作曲家は、100％安定しているわけではなく、1年前よりもはるかに優れていますが、それでも非常に活発なプロジェクトです。したがって、開発サーバー、ステージングサーバー、本番サーバーに同一の環境を実装するためにコンポーザーに依存することは、QA/デプロイメントグループからの一般的な推奨事項ではありません。これは、ジョルディにとってわずかなことではなく、QAの人々の気まぐれな性質の表現を意味します。
FAQから、ベンダーライブラリを独自のリポジトリにマージする場合は次のようにする必要があると記載されています。
タグ付きリリースのインストールに制限する（開発バージョンなし）
ただし、composerを使用してCIまたは自動デプロイを管理する場合は、同じ制約が適用されます。これは、マスターまたは開発タグを本番環境にデプロイすることが、1日だけのステージングでテストしたものとは非常に異なるパッケージになる可能性があるためです。 1時間前でも。
サードパーティのライブラリで導入された変更（開発または本番環境のデプロイメントに関係なく、タグ付きバージョンのみを使用することで解決されます）を除いても、コンポーザーが毎回まったく同じことを行うことに頼ることができない限り、本番環境にバグを導入するリスクがあります。これは実際にはリスクケースではありませんが、私も開発者です;）しかし、すべての環境でまったく同じバージョンのcomposer.pharを維持しない限り、このような単純な変更から問題が発生する可能性があります。ステージングサーバーまたは本番サーバーを実際に台無しにすることができます。
私が抱えている他の主要な問題は、この見出しの下にリストされているすべてのポイントに実際に関連しています。
一部の環境ではコミットしたくなるかもしれませんが、いくつかの問題が発生します。
結果を問題とは見なしませんが、代わりにメリットがあります。大規模なvcsリポジトリは、最新の高帯域幅環境ではそれほど大きな問題ではありません。また、非常にアクティブなベンダーライブラリを使用していない限り、差分もそれほど大きくなりません。それらが大きくても、git / hg / dvcsシステムはすべて、チャンクを再利用し、チャンクを圧縮し、すべてのアヒルを一列に並べることができます。しかし、それ以上に、これらのパッケージに変更が導入されたときに開発者に警告し、特にdev / masterタグを使用している場合は、変更diff -wセット全体の優れた要約ビューになります。
独自のVCSでのすべての依存関係の履歴の複製。
これは少し間違った言い方です。ベンダーライブラリのコミット履歴全体を複製するのではなく、現在から最後にコンポーザーの更新を実行して変更を加えたときまでの完全なデルタをカバーする単一のコミット（コミット）だけです。個々のパッケージを指定しなくても、更新するたびにすべてのライブラリを更新しているとは限りません。また、ベンダーライブラリを誤って更新した場合は簡単に元に戻すことができますが、dev / masterタグで更新して環境が壊れた場合は、以前に使用していたバージョンを特定し、でタグを指定する必要があります。 composer.jsonを作成し、再度更新して元に戻します。 git checkout /vendor/3rdpartylib --force私には簡単に思えます。
gitを介してインストールされた依存関係をgitリポジトリに追加すると、それらがサブモジュールとして表示されます。これらは実際のサブモジュールではないため、これには問題があり、問題が発生します。
理想的には、composerは設定オプションを提供します。git pullsから.gitディレクトリを自動的に削除し、更新されたバージョンが存在する場合にのみ、libを更新する前にディレクトリを自動的にrm（または一時的にmv）することができます。そして、そうすることは、その手動プロセスを個々の開発者に任せるよりもはるかに信頼性が高くなります。ベンダーライブラリをバージョン管理リポジトリに統合する理由は同じ数あるため、選択は実際には状況の詳細によって異なります。
すべてのファイルをバージョン管理する最大の理由は、開発でテストした正確なパッケージを本番環境にステージングするために確実にデプロイできることです。これは、vcsと自動デプロイメントの主な目的です。すべてのパッケージに特定のタグを使用するように開発環境を構成し、composer.pharのバージョン管理を行わない限り、ソフトウェアのデプロイをcomposerに依存しないでください。