残念ながら* Composer は Git サブモジュールをサポートしていません。Composer の主な目的は同様のプロジェクト間の依存関係機能を提供することであり、Composer でサブモジュールを複製しようとしても無意味です。
ライブラリを開発しながら、そのライブラリを使用するアプリケーションを同時に開発するという、あなたが解決しようとしているのと同じ問題があります。composer を使用するだけでこの問題を解決する方法がいくつかあります。
ライブラリ ディレクトリのシンボリック リンクを作成します。
これは、それを行うための最も迅速で汚い方法です。composer update を実行して、vendors ディレクトリにライブラリの適切なディレクトリを作成し、ライブラリを含むディレクトリからのシンボリック リンクに置き換えます。
composer update を実行して編集した可能性のあるコードを誤って上書きする可能性があるため、明らかにこれは良くありません。
Composer のソース優先オプションを使用する
--prefer-srcComposer には、デフォルトである zipball をダウンロードする ( ) のではなく、Git クローン ( ) を介してソースをダウンロードするオプション--prefer-distがあります。これにより、vendors ディレクトリ内のソース コードを編集し、Git 経由でコミットできます。
symfony/yamlたとえば、バグを修正したい他のライブラリの中で必要なプロジェクトがあるとします。あなたができることは次のとおりです。
composer update- これにより、プロジェクトのすべての依存関係がダウンロードされます。
composer update symfony/yaml --prefer-source- これによりsymfony/yaml、vendors ディレクトリ内のディレクトリのみが更新されます。
バグを修正してから、git でコミットします。
Composer のローカル リポジトリを使用する
私が --- 実際に --- 私がプロジェクトを開発していて、それが並行して必要であるときに使用していた方法は、Composers 機能を使用して、依存関係を解決するために使用するリポジトリを明示的に設定することです。たとえば、コードが次の場所にある場合:
/projects/library/
/projects/project/
プロジェクトのコンポーザ ファイルに、次のリポジトリ エントリを追加します。
"repositories": [
{
"type": "vcs",
"url": "/projects/library/"
}
]
実行composer updateすると、/projects/library/ の Git エントリが参照され、Packagist または他のリポジトリにリストされているものより優先して、ライブラリの依存関係が解決されます。
これは、ライブラリ コードの変更をテストする場合、次のことを行う必要があることを意味します。
Git エントリを持つようにコミットします。
プロジェクト ディレクトリで Composer update を実行して、最新バージョンを取得します。
ただし、コミットを外部リポジトリにプッシュする必要がなくなります。これは、動作しない可能性のあるコードをプッシュしないことを意味し、Git コミットはインターネット接続を必要としないため、オフラインで作業できることを意味します。
これは明らかに最善の作業方法ですが、ローカル ディレクトリへの参照を含む composer.json のバージョンを誤ってチェックインするのは簡単すぎて、明らかに他のすべてのプロジェクトが壊れてしまうため、危険です。
これを回避するために、i) 実際の composer.json ファイルをバックアップする、ii) いくつかのローカル リポジトリを追加する、iii) 実行する、composer updateiv) 実際の composer.json ファイルを復元する、いくつかの小さなスクリプトを作成しました。
localupdate.sh
cp -f composer.json composer.json.bak
php composerLocal.php
composer update
cp -f composer.json.bak composer.json
composerLocal.php
<?php
$srcFile = file_get_contents("composer.json");
$hackFile = file_get_contents("composer.local");
$finalString = str_replace('"LOCALHACK",', $hackFile, $srcFile);
file_put_contents("composer.json", $finalString);
?>
composer.local
"LOCALHACK",
"repositories": [
{
"type": "vcs",
"url": "/projects/library1"
},
{
"type": "vcs",
"url": "/projects/library2"
}
],
そして、プロジェクトファイル"//": "LOCALHACK",のどこかに配置します。composer.json実行localupdate.shすると、composer.json の悪いバージョンをコミットする可能性なしに、ローカル リポジトリに対して composer 更新が安全に行われます。
Git を使用して自分でクローンするだけです
これは私が今どのように仕事をする傾向があるかです：
i) プロジェクト内の Composer の更新 ii) vendors ディレクトリに移動し、同時に開発したいライブラリを削除します。iii) ライブラリを開発しているリポジトリから適切なベンダー ディレクトリに Git クローンを作成します。
Composer は git リポジトリを理解するので、git クローン ディレクトリを上書きしません (ただし、ライブラリの composer.json の編集について少し混乱しているようです)。
自分で git clone を実行すると、インストールされるものを完全に制御でき、プロジェクトで composer.json を編集することなく、composer が認識していないリポジトリまたはタグなしバージョンからインストールできます。
これが、自分で git clone を実行する際の重要な機能です。プロジェクトの composer.json に触れないことで、完全に安全になり、ローカル/カスタム リポジトリを使用するように変更された composer.json をチェックインする可能性がなくなります。
"//": "LOCALHACK"composer.json ファイルの検証が強化され、ファイルにエントリを含めることができなくなりました。これは、Composer の連中が Composer プロジェクトのバージョン管理を行っていない理由の 1 つです。
* 実際には、Git サブモジュールは、難しい問題を「解決」するための愚かな、愚かな、愚かな実装であり、今後さらに多くの問題を引き起こすだけだと思います。明らかに、他の人がそれらを使用して満足しているので、それは私の意見ですが、Composer を使用している場合は、サブモジュールは必要ありません。