作曲家包的Git工作流程？

Question

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

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

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

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

Answer 1

1. Composer 项目的源代码控制

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

发布后，一些步骤将是：

• 从发布分支/标签签出或克隆，
• 更新作曲家（自我更新）
• composer install（安装所有依赖到vendor目录）

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。
• 使用分支别名，例如，当您希望将主分支视为 2.0.x@dev 时。您可能想使用包 ABC 的 dev-master 分支，但碰巧您在项目中使用的包之一依赖于包 ABC 的 2.0 分支。由于您在项目中只能使用一个版本的包 ABC，因此您基本上要求所有其他包在他们想要使用 2.0.x@dev 分支时使用 dev-master

其他问题如最低稳定性和嵌套依赖在在线文档中很清楚，我在此不再赘述。