应如何管理 Zend Framework 2 项目的版本控制？是否有最佳实践/“标准方法”？ “子模块”是正确的关键字吗？
Zend Framework 2 项目通常是一个轻量级框架应用程序，具有各种已安装的模块，这些模块通常位于单独的专用存储库中。
主存储库通常不会受到许多更改的影响，因此您可以创建一个 git 存储库（Zend 骨架应用程序 https://github.com/zendframework/ZendSkeletonApplication） 为了它。虽然这些模块更相关并且需要小心处理，但框架应用程序通常在几个月内仅在几个细节上发生变化。
我可以建议以下方法：
- 创建应用程序特定模块的第一个版本：git 子模块 http://book.git-scm.com/5_submodules.html in the
modules/您的骨架应用程序分支的目录。
- 按照建议的方式处理模块，只需提交回原始存储库并更新根存储库中的 git 子模块引用即可。
- 一旦你有了一个相当好的工作版本（并且对composer http://getcomposer.org/和一般的 zf2），您可以通过添加一个将它们转换为 Composer 包composer.json http://getcomposer.org/doc/04-schema.md file.
- 删除转换后的 zf2 模块的 git 子模块并使用composer导入它 http://getcomposer.org/doc/04-schema.md#repositories反而。为此，您只需告诉 Composer 存储库所在的位置。这将使该模块可以在几秒钟内安装到您的任何应用程序上，帮助您重用现有组件。从现在开始，重新使用为不同项目编写的代码变得非常容易。
- 标记并逐步稳定软件包的依赖关系和版本（因为您将开始拥有自己的私人作曲家包生态系统 http://getcomposer.org/doc/articles/handling-private-packages-with-satis.md)
我个人就是这样做的，并且它已经变成了一个非常好的开发过程。每次共享功能时，我只需将其移动到新包并更新composer.json在模块中。Satis https://github.com/composer/satis剩下的事情就交给我们了，我们所有的实时系统的升级速度都非常快。
您可能想阅读更多内容有关作曲家的高级技巧和技巧 http://www.naderman.de/slippy/src/?file=2012-11-22-You-Thought-Composer-Couldnt-Do-That.html一旦你熟悉了它。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
