VCSでのMagento 2プロジェクトの推奨構造は何ですか？

新しいM2プロジェクトを開始するとき、最初に行うことは、composerを使用してコアをインストールすることです。

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition

これで、カスタムモジュールとテーマをで作成できますapp/code。次に、VCSにフォルダーcomposer.*全体を追加しapp/codeます。これまでのところ、すべてが正常です。

ここで、プロジェクトにいくつかのビルドツールを使用したいとします。GruntまたはGulpとしましょう。

1. 自分でコミットGruntfile.jsすると、リポジトリを複製した後にmagento/magento2-base実行すると、パッケージによって上書きされますcomposer install。

2. 私は私をコミットした場合gulpfile.js、私は本当に私の中で依存関係を定義することはできませんpackage.json、それはまたによって上書きされるため、magento/magento2-base。

3. MagentoのGruntセットアップを使用し、/dev/tools/grunt（たとえばthemes.js）の下のファイルを編集してカスタマイズしたい場合、変更がによって上書きされるため、できませんmagento/magento2-base。

私の理解では、ドキュメントルートではそれほど多くのことはできないということです。もちろん、この問題には多くの解決策があります。

• git checkout -インストール直後に実行して自分のファイルをリセットできました
• /buildたとえば、ビルドファイルを専用フォルダーに保存できます。
• Phing、Ant、Rakeなどの別のビルドツールを使用できます（ただし、フロントエンドの開発者はそれほど満足しません）
• magento/magento2-baseコアファイルのカスタムマッピングを持つカスタムパッケージに置き換えることができます（実際には最適ではありませんが、オプションです）

私は個人的にこれらのオプションをすべて嫌うので、私がやろうとしていることを達成するための好ましいまたはより良い方法があるかどうか知りたいです。

誰も同じ問題を抱えていますか？どのように解決しましたか？VCSでプロジェクトをどのように構成しますか？

更新

プロジェクトのセットアップに関連する追加のポイント。私の実験では、Magento composerインストーラーがファイルオーバーライドのフラグを持っていることに気付きました。

"extra": {
    "magento-force": "override"
}

間違っていない場合は内部的にブール値として扱われるため、falseオーバーライドをスキップするように設定しようとしました。composer installファイルが既に存在するため、インストールを実行すると失敗します。基本的に、Magentoにファイルを上書きさせない場合、インストールできません。

このフラグの目的は何ですか？私のためにチェックを実行することだけを想定していますか？正直に言うとあまり意味がありませんが、誰かが主題に光を当てることができるかもしれません。

短い言葉ですが、カスタマイズが必要なファイルを個別に探しています。たとえば、index.phpを変更する必要がある場合、Magentoが出荷する標準ファイルをローカルカスタマイズの必要性から分離する方法を考えてください。達成されると、「すべてのプロジェクトが使用できる真の.gitignoreを1つ」持つことができます。つまり、「composer install」が取得するすべての.gitignoreを使用して、プロジェクトディレクトリ全体をGitに簡単にコミットできます（「composer update」はパッチまたはアップグレードをインストールするときにすべて置き換えられます）。

長期的には、目標は.gitignoreをできるだけ短くすることです。たとえば、「vendor」ディレクトリの下のモジュールにさらにプッシュします。

それから

1. プロジェクト間で共有したくないすべてのものについては、アプリ/コードの下に置き、メインのプロジェクトリポジトリにコミットします。
2. ローカルで開発されたものはすべて、プロジェクト間でより簡単に共有し、別のGITリポジトリに配置し、コンポーザーを介してインストールするため、最終的に「ベンダー」になります。（ローカルの作曲家レポか、GITから直接インストールすることもできます。）

そうすることで、プロジェクトツリー全体をトップダウンでgitコミットし、composer.jsonファイルとcomposer.lockファイルをキャプチャできます（app / codeだけをコミットすることはできません）。.gitignoreは、「ベンダー」ディレクトリと不要なその他のファイルを除外します。

これにより、他の議論で言及した両方の長所が得られます。現在の痛みは.gitignoreファイルの長さと複雑さであり、パッチのインストールは現在、ローカルカスタマイズ（index.phpなど）を一掃します。短期的な回避策-index.phpを.gitignoreから削除し、パッチチェックをインストールするときに失われた変更を確認し（git diff）、手動で再適用します。

オーバーライドの問題には簡単な解決策があります。コアファイルを変更しないでください;）Magentoは、コードを拡張することに基づいており、コードを変更することはありません。

まず、1つのvcsリポジトリにapp / codeフォルダー全体を配置しないでください。各Magentoコンポーネント（モジュール、テーマなど）は、リポジトリ自体でなければなりません。

フロントエンドを変更/拡張する場合は、新しいテーマを作成し、このテーマをMagento2インスタンス全体ではなく、うなり声の多いプロジェクトとして扱う必要があります。

プロジェクトにテーマをインストールするには、vcsリポジトリから直接composerを介して簡単にプルできます

OK、私が達成しようとしていたものに対してより良い解決策を見つけたようです。では、composer.jsonMagento Composerインストーラーによって無視されるファイルを指定することができます。Gruntfile.jsオーバーライドしたくない場合は、次の構成で簡単に指定できます。

"extra": {
    "magento-deploy-ignore": {
        "magento/magento2-base": [
            "/Gruntfile.js",
            "/package.json"
        ]
    }
}

これで、標準インストールを自分のニーズに合わせて拡張できます。

残念ながら、受け入れられた答えは、本来目的の目標を達成するための方法ですが、ルートに配置されたファイルとディレクトリを除外する場合にのみ機能します。サブディレクトリに配置されたファイルを除外するdev/tools/grunt/configs/themes.js場合新しいテーマでMagento Gruntタスクを使用したい場合）、「magento-deploy-ignore」構成に設定すると、すべての親ディレクトリ（つまり、devおよびそのすべてのサブディレクトリ）のデプロイがブロックされます。

これは、「magento-deploy-ignore」（\MagentoHackathon\Composer\Magento\Deploystrategy\DeploystrategyAbstract::isDestinationIgnored）を処理するメソッドがstrpos宛先パスを除外リストと照合するために使用されるため、すべての親パスが常にtrueを返すために発生します。

パッチを使用する

私が使用しているのは、パッチの作成と適用です。変更する必要がある場合dev/tools/grunt/configs/themes.js、index.phpまたは.htaccessファイルの一時コピーに変更を適用し、そこからパッチを作成します（build/最初にディレクトリを作成します）。

$ cp dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp
  # Now Make changes in .tmp file
$ diff -u3 dev/tools/grunt/configs/themes.js dev/tools/grunt/configs/themes.js.tmp | sed 's/\.tmp//' > build/themes.patch
$ mv dev/tools/grunt/configs/themes.js.tmp dev/tools/grunt/configs/themes.js

次に、実行時にこのパッチを自動的に適用するcomposer installか、ファイルのセクションにupdateteコマンドを追加します。scriptscomposer.json

{
    "scripts": {
        "post-install-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js",
        "post-update-cmd": "patch -i build/themes.patch dev/tools/grunt/configs/themes.js"
    }
}

（上記のpatch ...コマンドをbashスクリプトに入れてbuild/themes_patch.sh、Composerからそのスクリプトを呼び出して、再利用可能にするか、手動で実行できるようにすることもできます）

安全にアップグレード！：D

このソリューションはアップグレードしても安全です！元のファイルを尊重せずにコアファイルを直接変更することはありません。元のMagento2ファイルにパッチを適用しています。アップグレード中にそのファイルが変更されると、パッチは失敗し、新しい変更を詳しく調べて新しいパッチを作成する必要があることがわかります。