模块开发的版本控制

我想知道，就版本控制而言，是否有任何良好的约定来开发在单个Magento实例中使用并且还希望作为社区模块发布的模块。

最初，我试图做的是使用modman在我的主要Magento实例存储库之外管理模块。但这最终在多个层面上带来了问题。拥有一个可以轻松安装到不同环境或在生产中回滚的单一存储库非常有用，我什至说这已经成为我工作流程中的必要部分。

我目前正在做的事情是在网站存储库内部进行开发，并计划将其分解为一个单独的存储库。到那时，我可能会做的是：

• 使用modman在单个模块存储库中的本地环境中构建
• 准备部署代码时，将更改复制到网站存储库中

希望有更好的方法？

我们有几个模块可以完成此操作，而实际上我们要做的是：

• 为模块设置一个Git存储库。
• 将此模块部署到生产站点的代码库中，并提交所有内容，包括：
  • Modman创建的软链接
  • .modman目录，其中包含克隆的模块存储库
• 使用modman将其“部署”到其他版本和/或dev环境中，以进行开发和测试。

这样可以为您提供模块开发所需的灵活性，也可以在单个站点上对代码进行版本控制，并且如果您在单站点代码库中对模块进行了更改，则可以将这些内容直接提交给模块存储库，因为该仓库位于.modman目录中。

更新： 当我最初写这篇文章时，我没有考虑我的回答，即Git不允许将（子）模块提交到存储库，在这种情况下，“提交所有内容”需要一些阐述！

顺便说一句，这是因为我经常使用modman来将Git仓库中的模块部署到SVN所拥有的生产代码库中，并且Subversion毫不顾忌地阻止了它将整个Git树提交给VCS。

所以这里...

1. 如果您使用SVN来存储生产站点的代码，则应该没有问题，因为Subversion（实际上）没有子模块的概念。没关系

2. 如果将Git用于生产站点的代码，则必须使用子模块将所有内容“提交”到站点的代码存储库。在使用modman克隆如下代码之后：

   modman clone ssh://git@bitbucket.org/<user>/<repo>.git

   您还希望将其添加为子模块，如下所示：

   git submodule add ssh://git@bitbucket.org/<user>/<repo>.git .modman/<repo>

   完成此操作后，您应该可以将.modman目录和.gitmodules文件添加到索引并提交它。

   克隆使用通过modman安装的这些模块的存储库后，只需初始化子模块并更新：

   git submodule init
   git submodule update

PS我现在在所有新项目上全职使用Git，因此希望这种监督不会再次发生。对不起大家。;）

当前的约定似乎为以下方面提供支持：

• 作曲家-http: //getcomposer.org/
• 莫德曼-https: //github.com/colinmollenhour/modman
• Github回购

就目录结构而言，它几乎是最少的，最好将模块安装在社区代码池中。

建议的最低目录结构为：

.
└── app
    ├── code
    │   └── community
    │       └── YourCompany
    │           └── YourModule
    │               ├── Block
    │               ├── Model
    │               │   └── Observer.php
    │               └── etc
    │                   └── config.xml
    ├── design
    │   └── frontend
    │       └── base
    │           └── default
    │               ├── layout
    │               │   └── module.xml
    │               └── template
    │                   └── yourmodule
    └── etc
        └── modules
            └── YourCompany_YourModule.xml

可选/必备：

• Github登陆页面，带有说明，一些屏幕截图和一些项目符号功能。
• 链接到已安装的演示商店也很好
• 屏幕截图/两分钟的产品概述

编辑：我可能误会了。

结合使用modman / gitignore可以使模块与测试环境保持隔离。使用上面的文件夹结构，您可以明确地仅允许将模块的文件提交/安装到您的仓库中。在这种情况下，大卫的答案更适用。Modman对dev / deploy的支持似乎是共识。

即使我自己还没有尝试过，我还是建议您使用作曲家。

版本控制，包括依赖项

通过将composer.lock文件保留在存储库中，可以修复所有模块的版本，并且始终可以使用VCS（git checkout，svn ..），然后按来还原特定版本（分支，标记或较旧的版本）composer.phar install。

缺点

出现的问题是，您的部署很容易依赖多个来源（例如GitHub），从而导致多个故障点。

因此，我们需要某种缓存或代理来存储这些模块，以便我们始终能够进行部署。

Satis似乎能够达到这个目的（请参阅https://github.com/researchgate/broker）和我的问题/programming//q/16211671/288568

卡伦

也许我不太了解您的工作流程，但是听起来您是在本地的magento回购中开发，然后分离为modman回购。为什么不直接在IDE中编辑./modman/modulesname/CONTENTS，然后按照与开发相同的工作流程，将代码独立地推送到模块仓库中。您可以使用modman部署到生产环境，也可以与cli中的.modman / modulesname /文件夹中的单个存储库进行交互，也可以通过向IDE中添加版本控制源进行交互，尽管实际上使用.basedir可以将存储库链接路径保留在您的外部webroot将会发挥得更好。

modman还有一个非常好的功能，很多人似乎没有使用过。bash脚本解释.modman存储库中的.basedir文件，如果该文件不存在，则modman将modman文件中的符号链接规则应用于与.modman文件夹相同的级别...如果存在.basedir文件，则内容描述了一个子文件夹，该子文件夹是您的Magento代码的顶层（从.modman路径向下）。换句话说，您可以运行（而且我也可以）在文件夹中运行所有基本Magento版本，例如“ BaseMagento1.9.1.0” 'BaseMagento1.14.2.0'和modman初始化包含它们的文件夹。在.modman路径中添加.basedir文件，您可以轻松更改内容。这对于版本测试非常有效。