使用构建、依赖管理器和 GIT 进行部署的最佳方式？
Best way for deployments with builds, dependency managers and GIT?
我目前正在使用 Git、Git Flow、Gulp 和 Bower。我正在 develop 分支上工作，并使用 Git 流程创建版本到 master 分支。所以develop等于我的本地和测试环境，release/version等于验收环境，master分支等于生产环境。参见：http://nvie.com/files/Git-branching-model.pdf。在每个环境 运行s Git 上，所以部署无非就是：git pull origin master.
我有一些依赖项，例如 Bootstrap 和使用 Bower 处理的 Font Awesome，我正在使用 Gulp 观看 .less 文件 "compiling" 到 css，缩小 css/js，等等
现在回答问题：我的 Git 存储库中应该有什么？假设我正在处理一个 Magento 项目，将 Magento 和 Bower 的所有依赖项放入存储库中就太过分了。目前我只排除 node_modules（对于 Gulp）和 bower_components（包含依赖项）目录，当我 运行 Gulp .less来自 Bootstrap 的文件将是 "merged" 和 "compiled" 与我的项目相关的 .less 文件。 "compiled" .css 文件当前包含在我的存储库中，否则无法仅使用 git pull 进行部署。要使其在 Git 中没有 "compiled" 版本的情况下工作，我必须在生产服务器上 运行 Gulp。
在我的 Git 存储库中没有我的平台（Magento 或 Wordpress）但保持轻松更新的可能性的最佳方法是什么？我遇到了这个解决方案：http://blog.g-design.net/post/60019471157/managing-and-deploying-wordpress-with-git where they're using Git Submodules。不错的解决方案，但这样平台需要位于子目录中。不理想，因为我必须 "hack" 让它以这种方式工作（复制 index.php 并更改包含路径等）。
那plugins/modules呢？第 3 方插件也不应该在我的存储库中吗？只有我自己创建的插件。但并非所有第 3 方插件都具有 Git 存储库以用于例如 Git 子模块。对于 Wordpress 它只是一个目录，所以理论上它是可能的但是对于 Magento 大多数插件不只是一个目录（它们在 app/code、app/design、skin 等目录中有文件).我有很多具有多个匹配 plugins/modules 的 Wordpress 和 Magento 站点，现在每个 plugin/module 都在每个站点存储库中。
"compiled" 文件应该在存储库中吗？如果你问我：不，但我目前正在这样做，所以它很容易部署。通常在生产服务器上安装 Bower 和 运行 Gulp 以获得依赖关系，并在 git pull 之后立即在生产服务器上安装 "compile" 吗？继续 运行生产 Gulp 观察者（就像我在本地做的那样）需要一些额外的不必要的资源？
我希望有人能给我指明正确的方向。
很难提供适用于 Magento、WordPress 和其他平台的通用答案。我的回答主要针对 Magento，但我确信类似的概念可以应用于 WordPress 和其他平台。
可以使用 Composer with magento-composer-installer. You can either use a public mirror, like this one 自动安装 Magento 作为依赖项，或者设置您自己的存储库。一旦您将 Magento 本身安装为依赖项，就应该非常直接地更新它，就像任何其他依赖项一样。
您也可以将 Composer 用于模块（毕竟，Magento 本身只是一堆模块和一些将所有内容粘合在一起的脚本）。 FireGento 有很多通用的 Magento 模块，可以开箱即用地与 Composer 一起使用。您还可以设置自己的存储库以与 Composer 一起使用（我们对用于多个站点的内部模块执行此操作）。
至于那些没有自己的仓库的模块，嗯，你有三个选择：不使用它们（模块越少越好），为它们创建你自己的仓库，或者只是一起提交它们与您的其余代码库。
在理想情况下，您的存储库应该只包含您自己的源文件。其他一切——无论是编译的、通过依赖管理器安装的，还是以其他方式自动创建的——都不应该在存储库中。
但我们并没有生活在一个理想的世界中 - 运行 Composer、Bower、Git、Gulp、Sass 以及其他一切都是痛苦的您在要部署到的每个环境（开发机器、测试服务器、临时服务器、生产服务器等）上使用。
如果这些依赖关系有依赖关系怎么办？如果您使用的 Gulp 插件在您的一台服务器上运行良好，但在另一台服务器上运行失败怎么办？如果有人进行部署并忘记通过 Gulp 运行 一些必需的构建怎么办？当然，这些问题的答案是测试和自动化。您应该能够单击一个按钮（或键入一个命令，对于纯粹主义者）并自动部署所有内容 - 发出 git pull，适当的 gulp 命令是 运行，等等在。但是除非你有足够的人力和工时来建立这样一个复杂的系统，否则是不值得的。
总的来说，我们结合了以上不同点。最后，我们最终将（几乎）所有内容提交到存储库 - 导致部署像 git pull 或 svn up 一样简单。当然，配置文件（凭据、.htaccess 文件等）不会进入存储库，指纹文件（我们手动上传）也不会。
Fabrizio Branca 有一篇很棒的博客 post here，其中介绍了许多描述的要点，以便清理和升级 Magento 设置。
我目前正在使用 Git、Git Flow、Gulp 和 Bower。我正在 develop 分支上工作，并使用 Git 流程创建版本到 master 分支。所以develop等于我的本地和测试环境，release/version等于验收环境，master分支等于生产环境。参见：http://nvie.com/files/Git-branching-model.pdf。在每个环境 运行s Git 上，所以部署无非就是：git pull origin master.
我有一些依赖项，例如 Bootstrap 和使用 Bower 处理的 Font Awesome，我正在使用 Gulp 观看 .less 文件 "compiling" 到 css，缩小 css/js，等等
现在回答问题：我的 Git 存储库中应该有什么？假设我正在处理一个 Magento 项目，将 Magento 和 Bower 的所有依赖项放入存储库中就太过分了。目前我只排除 node_modules（对于 Gulp）和 bower_components（包含依赖项）目录，当我 运行 Gulp .less来自 Bootstrap 的文件将是 "merged" 和 "compiled" 与我的项目相关的 .less 文件。 "compiled" .css 文件当前包含在我的存储库中，否则无法仅使用 git pull 进行部署。要使其在 Git 中没有 "compiled" 版本的情况下工作，我必须在生产服务器上 运行 Gulp。
在我的 Git 存储库中没有我的平台（Magento 或 Wordpress）但保持轻松更新的可能性的最佳方法是什么？我遇到了这个解决方案：http://blog.g-design.net/post/60019471157/managing-and-deploying-wordpress-with-git where they're using Git Submodules。不错的解决方案，但这样平台需要位于子目录中。不理想，因为我必须 "hack" 让它以这种方式工作（复制
index.php并更改包含路径等）。那plugins/modules呢？第 3 方插件也不应该在我的存储库中吗？只有我自己创建的插件。但并非所有第 3 方插件都具有 Git 存储库以用于例如 Git 子模块。对于 Wordpress 它只是一个目录，所以理论上它是可能的但是对于 Magento 大多数插件不只是一个目录（它们在
app/code、app/design、skin等目录中有文件).我有很多具有多个匹配 plugins/modules 的 Wordpress 和 Magento 站点，现在每个 plugin/module 都在每个站点存储库中。"compiled" 文件应该在存储库中吗？如果你问我：不，但我目前正在这样做，所以它很容易部署。通常在生产服务器上安装 Bower 和 运行 Gulp 以获得依赖关系，并在
git pull之后立即在生产服务器上安装 "compile" 吗？继续 运行生产 Gulp 观察者（就像我在本地做的那样）需要一些额外的不必要的资源？
我希望有人能给我指明正确的方向。
很难提供适用于 Magento、WordPress 和其他平台的通用答案。我的回答主要针对 Magento，但我确信类似的概念可以应用于 WordPress 和其他平台。
可以使用 Composer with magento-composer-installer. You can either use a public mirror, like this one 自动安装 Magento 作为依赖项，或者设置您自己的存储库。一旦您将 Magento 本身安装为依赖项，就应该非常直接地更新它，就像任何其他依赖项一样。
您也可以将 Composer 用于模块（毕竟，Magento 本身只是一堆模块和一些将所有内容粘合在一起的脚本）。 FireGento 有很多通用的 Magento 模块，可以开箱即用地与 Composer 一起使用。您还可以设置自己的存储库以与 Composer 一起使用（我们对用于多个站点的内部模块执行此操作）。
至于那些没有自己的仓库的模块，嗯，你有三个选择：不使用它们（模块越少越好），为它们创建你自己的仓库，或者只是一起提交它们与您的其余代码库。
在理想情况下，您的存储库应该只包含您自己的源文件。其他一切——无论是编译的、通过依赖管理器安装的，还是以其他方式自动创建的——都不应该在存储库中。
但我们并没有生活在一个理想的世界中 - 运行 Composer、Bower、Git、Gulp、Sass 以及其他一切都是痛苦的您在要部署到的每个环境（开发机器、测试服务器、临时服务器、生产服务器等）上使用。
如果这些依赖关系有依赖关系怎么办？如果您使用的 Gulp 插件在您的一台服务器上运行良好，但在另一台服务器上运行失败怎么办？如果有人进行部署并忘记通过 Gulp 运行 一些必需的构建怎么办？当然，这些问题的答案是测试和自动化。您应该能够单击一个按钮（或键入一个命令，对于纯粹主义者）并自动部署所有内容 - 发出
git pull，适当的gulp命令是 运行，等等在。但是除非你有足够的人力和工时来建立这样一个复杂的系统，否则是不值得的。
总的来说，我们结合了以上不同点。最后，我们最终将（几乎）所有内容提交到存储库 - 导致部署像 git pull 或 svn up 一样简单。当然，配置文件（凭据、.htaccess 文件等）不会进入存储库，指纹文件（我们手动上传）也不会。
Fabrizio Branca 有一篇很棒的博客 post here，其中介绍了许多描述的要点，以便清理和升级 Magento 设置。