リポジトリ構成の vcs を介して BitBucket (git リポジトリ) から依存関係をインストールすると、リポジトリのクローンが作成されます。次に、親プロジェクトをコミットすると、ファイルはコミットされず、依存関係リポジトリへのリンク参照のみがコミットされます。
どうすれば
a) これらのファイルを親 git リポジトリにコミットします。それらが BitBuckets インターフェイス (および他のクローンまたはダウンロードされた zip ファイル) に表示されるようにします。
b) リポジトリを複製する代わりに、依存関係のために zip ファイルをダウンロードするように composer に指示します。composer.json で "preferred-install": "dist" を指定しましたが、何もしませんでした。注: これはプライベート リポジトリです。
/vendorまず、ディレクトリ (またはこのディレクトリとして機能するように定義した場所)に作成されたリポジトリから編集および/またはコミットすることは想定されていません。
通常、他の誰かからライブラリをインクルードし、外部リポジトリよりもコミット権を持っているとは思われません。変更や機能の実装が必要な場合は、プル リクエストや課題トラッカーなどのワークフローが存在する可能性があります。更新を取得するには、新しいバージョンが表示されるのを待ってから に電話しますcomposer update。
独自のライブラリにも同じ規則が適用されます。/vendorメイン プロジェクトでa を介してディレクトリを除外しない場合.gitignore、Composer によって複製されたリモート リポジトリは git サブモジュールとして扱われることに注意してください。その場合、サブモジュールを持つための通常のルールが適用されると思います（それらの経験はありません）。
しかし、私はそのように開発しないことをお勧めします。実際には、それぞれが独自に機能する 2 つの異なるリポジトリが必要です。ライブラリはメイン プロジェクトとは別に開発する必要があり、そこでの開発は BitBucket にプッシュできます。その後、Composer を使用してベンダー ディレクトリを更新できます。
ZIP ダウンロード: リポジトリが Github でホストされている場合、Composer には特別なケースの処理があります。Github は、タグ、ブランチ、またはコミット ID をキーとして、リポジトリの ZIP ボールをダウンロードするためのインターフェイスを提供します。これらのダウンロードは誰でも読み取り可能であるため、認証の問題はありません。
独自のライブラリで、そのバージョンの ZIP ファイルのダウンロード場所を提供することもできます。しかし、手動で行う場合、常に正しく維持されていることを確認するのはかなり面倒です。これにはソフトウェアを使用することをお勧めします: Satis (詳細な説明)。
Satis は、開発マシンからアクセスできる Web サーバーでホストする必要がある少なくとも 2 つの静的ファイルを作成し、必要に応じて、リポジトリで見つかったすべてのタグの ZIP ファイルを作成することもできます。
次に、メイン プロジェクトのリポジトリの手動参照を、その Satis ホスティング Web サーバーへの単一のポインターに変更します。
また、リポジトリの 1 つで新しいタグを作成するたびに、Satis を再度実行して新しい情報を取得し、新しい ZIP ファイルを作成します。
ZIP ダウンロードの場所を指定した場合にのみ、preferred-install=distオプションとの違いが発生します。ダウンロード場所がない場合、Composer は常に元のリポジトリを複製します。