php - Composer 包的 Git 工作流程？

Question

我最近一直在为 Composer 开发很多包，因为我们公司正在转向 Composer 进行包管理，但我遇到了如何处理版本的问题。

我一直在使用 git 工作流程和标记版本，但这意味着我无法返回到以前的主要或次要版本并为其制作补丁版本。我在理解标记开发/测试版/RC 版本如何与 Composer 一起工作方面也遇到了问题。

我见过其他项目使用分支别名，我认为它可能会为我解决这些问题，但在阅读了有关它们的 Composer 文档后，我仍然觉得我不明白如何实际使用它们。

有更多使用 Composer 经验的人是否有关于如何最好地对 git 包存储库进行版本控制的提示/技巧？

Answer 1

<强>1。 Composer项目的源代码控制

我通常使用 .gitignore 忽略供应商目录。事实上，这种情况很常见，大多数 PHP 框架附带的 .gitignore 文件已经包含了供应商目录。

发布后，一些步骤将是:

• 从发布分支/标签 checkout 或克隆，
• 更新 Composer ( self 更新)
• composer 安装(将所有依赖项安装到供应商目录中)

<强>2。 Composer 版本控制/稳定性/别名混淆

是的，这很令人困惑，我认为最令人困惑的部分是版本的来源，并且在在线文档中不容易找到。版本来自源代码控制的分支和标签

• 标签名称是确切的版本名称。如果您有一个名为“xx”的标签，则可以在 package.json 文件中将其引用为“xx”。如果您的标签遵循语义命名约定(例如 1.0.1 或 v1.0.1)，您可以使用类似 ~1.0.* 的语义语法来引用它。
• 标签是“稳定的”，除非它们的语义名称包含“RC1”、“RC2”、“alpha”等内容(例如 1.0.1-rc1、1.0.1-alpha)。在这些情况下，它们可以通过1.0.1@RC 或 1.0.1@alpha。
• 默认情况下分支不是“稳定”的，编号的分支将被视为开发版本。例如分支 2.0 将被引用为 2.0.x-dev (注意额外的 .x )；非编号分支名称将通过前缀“dev-”进行引用。即“master”分支成为 dev-master，“testing”分支成为 dev-testing。
• 例如，当您想将 master 分支视为 2.0.x@dev 时，可以使用分支别名。您可能想要使用包 ABC 的 dev-master 分支，但碰巧您在项目中使用的包之一依赖于包 ABC 的 2.0 分支。由于您在项目中只能使用 ABC 包的一个版本，因此您基本上要求所有其他包在想要使用 2.0.x@dev 分支时使用 dev-master

其他问题(例如最小稳定性和嵌套依赖项)在在线文档中已经很清楚，我不再在这里重复。