在VCS下，Magento 2项目的首选结构是什么？

当我开始一个新的M2项目时，我要做的第一件事是通过composer安装核心：

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

现在，我可以在下编写我的自定义模块和主题app/code。然后，我composer.*将整个app/code文件夹添加到我的VCS中。到目前为止，一切都很好。

假设现在我想为我的项目使用一些构建工具，比如说Grunt或Gulp。

1. 如果我自己提交Gruntfile.js，克隆仓库后magento/magento2-base运行时，它将被程序包覆盖composer install。

2. 如果我提交了我gulpfile.js，我真的不能在a中定义我的依赖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作曲家安装程序具有文件覆盖标志：

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

如果我没记错的话，它在内部被视为布尔值，因此我尝试将其设置false为跳过重写。当我运行时composer install，由于文件已存在，安装失败。基本上，如果我不让Magento覆盖文件，就无法安装。

那么，该标志的目的是什么？是否只想对我进行检查？老实说，这对我来说没有多大意义，但也许有人可以阐明这个话题。

简而言之，我们正在寻找需要定制的文件。例如，如果人们需要修改index.php，请找出如何将Magento随附的标准文件与本地自定义需求分开。一旦实现，就有可能有一个“所有项目都可以使用的真正的.gitignore”。也就是说，使用.gitignore可以轻松地将整个项目目录提交给Git，这是“ composer install”将为您获取的所有内容（而在安装补丁或升级时，“ composer update”将替换的所有内容）。

从长远来看，目标是尽可能缩短.gitignore。例如，将更多内容推送到“ vendor”目录下的模块中。

然后

1. 对于您不想在项目之间共享的所有内容，请将其保留在应用程序/代码下并在主项目存储库中提交。
2. 您希望本地开发的所有内容都可以更轻松地在项目之间共享，放在单独的GIT存储库中并通过composer安装，这样最终可以归到“供应商”之下。（可以是本地作曲家仓库，也可以直接从GIT安装。）

这样，您仍然可以从上至下git提交整个项目树，捕获composer.json和composer.lock文件（仅提交应用程序/代码不会）。.gitignore将排除“ vendor”目录和其他不需要的文件。

这使您在其他讨论中提到的两全其美。当前的痛苦是.gitignore文件的长度和复杂性，补丁程序安装目前消除了一些本地自定义（例如，在index.php中）。短期解决方法-从.gitignore中删除index.php，并在安装补丁程序时检查丢失的更改（git diff），然后手动重新应用。

有一个简单的解决方案可以解决您的问题：不要更改核心文件；）Magento基于扩展代码而不更改代码。

第一件事是，您不应该将整个应用程序/代码文件夹放在一个vcs存储库中。每个Magento组件（模块，主题等）都应该是一个存储库。

如果要更改/扩展前端，则应创建一个新主题并将该主题视为您的grunt项目，而不是整个Magento2实例。

要在您的项目中安装主题，您可以通过composer轻松地直接从vcs存储库中提取主题

好的，看来我为自己要实现的目标找到了更好的解决方案。在中composer.json，可以指定Magento 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或者update通过scripts在composer.json文件部分添加te命令来自动应用此补丁：

{
    "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文件。当该文件由于要升级而更改时，该修补程序将失败，并且您知道必须仔细查看新更改并创建新的修补程序。