作曲家包的Git工作流程？

Question

我最近为作曲家开发了很多软件包，因为我们公司正在转向使用作曲家进行软件包管理，但我遇到了如何处理版本的问题。

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

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

有没有使用作曲家经验的人有关于如何最好地对git包存储库进行版本化的提示/技巧吗？

Answer 1

<强> 1。作曲家项目的源控制

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

发布后，部分步骤将是：

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

<强> 2。作曲家反思/稳定/别名混淆

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

• 标签名称是确切的版本名称。如果你有一个名为'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。
• 默认情况下分支不是“稳定”，编号分支将被视为开发版本。例如branch 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

最小稳定性和嵌套依赖关系等其他问题在在线文档中很清楚，我在此不再重复。