私たちは多くのカスタムライブラリとサードパーティのライブラリを持つ複合プロジェクトを持っています。 私たちはコンポーザーアップデートでサブプロジェクトのほとんどを更新する方法を探しています。 しかし、安全性のために、すべてのサブ依存関係を現在インストールされているバージョンにロックダウンする必要があります。私がタグ付けされたバージョンで問題はなかったが、「DEV-マスターは」私の悩みdev-master依存関係の更新を無効にする
を与えるロックの依存関係「いくつか/ FU」缶
：「DEV-マスター」
（現在のバージョンと0.1 ）それはそのままで、0.2に更新されることはありませんか？
問題はdev-masterが動いているということです。したがって、dev-masterの意味はいつでも変更できます。
最新の1.0開発版を表しているとします。ある時点で言っライブラリの作者は1.1リリースで作業を開始するので、彼らは1.0枝を分岐し、dev-masterは、自動的に最新の1.1のdevのバージョンになります。
技術的には、dev-masterにはバージョンがありません。は、バージョン番号です。これは、マスターブランチの最新の開発状態を表しています。
、あなたがbranch aliasを利用することができ必要とするソースリポジトリを管理している場合。
composer update vendor/package1 vendor/package2のような特定のパッケージのみを更新することも、完全なcomposer updateの代わりに特定のベンダーcomposer update vendor/*を短縮することもできます。私が知る限り、特定のパッケージをまだ更新から除外することはできません。答えを@Pehに加えて
：
はい、dev-masterを使用して悪い習慣です。しかし、本当に必要な場合は、特定のコミットを拾うことができます"symfony/finder": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"
masterブランチではどのようなシナリオが問題につながりますか？いつあなたはcomposer updateを実行しますか？
はい、これは特定のコミットに固執し、決して*更新しません。もう1つのアプローチは、パッケージをフォークすること（そしてフォークを必要とする）で、好きなコミットを選ぶことです。変更/更新を完全に制御できます。 –
はい、私はあなたに同意します。それはいくつかの長所と短所を持つ別のアプローチです。 –