Zend Framework 2如何/应该包含在Git版本化的项目中？

问题描述

如何管理Zend Framework 2项目的版本控制？对此有最佳实践/标准方法吗？ Zend框架2项目通常是一个轻量级的骨架应用程序，它具有各种已安装的模块，它们是通常在单独的专用存储库中。

主存储库通常不会受到许多更改的影响，因此您可以创建一个git存储库（）。尽管这些模块更具相关性并且需要一定的关注，但骨架应用程序通常只会在几个月内改变一些细节。

我可以推荐以下方法：

1. 创建应用程序特定模块的第一个版本，如在您的骨架应用程序分支的 modules / 目录中。


2. 模块以建议的方式，只需提交回原始存储库并更新根存储库中的git子模块引用即可。


3. 一旦你有一个相当好的工作版本（并有一定的信心和zf2），您可以通过添加一个档案。


4. 删除转换的git子模块而不是使用ted zf2模块和。要做到这一点，你只需要告诉作曲家仓库的位置。这将使该模块可以在任何应用程序上以秒为单位安装，帮助您重新使用现有组件。重新使用您为不同项目编写的代码变得非常简单。


5. 标记并逐步稳定包的依赖和版本（因为您将开始拥有自己的）

ol>



这就是我亲自操作的方式，它已经变成了一个非常好的开发过程。每次共享一个功能时，我只需将它移动到一个新包中，并更新模块中的 composer.json 。 负责其余部分，我们所有的在线系统都可以快速升级。





您可能想要阅读更多，一旦你熟悉了。




How should the version controlling of a Zend Framework 2 project be managed? Is there a best practice / "standard approach" for this? Is "submodule" the right keyword?

解决方案

A Zend Framework 2 Project is usually a lightweight skeleton application with various installed modules, which usually are on separate dedicated repositories.

The main repository isn't usually affected by many changes, so you can create a git repository (fork of ZendSkeletonApplication) for it. While the modules are more relevant and require some care, the skeleton application usually changes only in a couple details over the months.

I can suggest following approach:

1. create your first versions of the app-specific modules as git submodules in the modules/ directory of your skeleton application fork.
2. work on the modules in the suggested way, by simply committing back to the original repositories and updating the git submodule references in the root repository.
3. Once you have a fairly well working version (and have some confidence with composer and zf2 in general), you can convert them into composer packages by adding a composer.json file.
4. Remove the git submodule of the converted zf2 module and use composer to import it instead. To do so, you will simply need to tell composer where the repository is located. This will make the module installable in seconds on any of your applications, helping you in re-using existing components. Re-using code you wrote for different projects becomes really easy from now on.
5. tag and progressively stabilize dependencies and versions of your packages (because you will start to have your own private composer packages ecosystem)

This is how I personally do it, and it has turned into a very nice development process. Each time a feature is shared, I simply move it to a new package and update the composer.json in the modules. Satis takes care of the rest, and all our live systems are very fast to upgrade.

You may want to read some more advanced techniques and tips and tricks about composer once you are familiar with it.

这篇关于Zend Framework 2如何/应该包含在Git版本化的项目中？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！