目标：
开发 git 工作流和管道模式来管理基于节点的应用程序或 npm 包的开发、测试和发布。

问题（在我看来）： 如果我使用带有预发布限定符（例如 -beta.0、-beta.1）的 npm version 作为构建/部署的版本，这就是 QA 将在给定环境中验证/测试的内容。一旦经过验证/认证，我就没有构建、标记和部署最终版本。因此，我必须通过运行 npm version 并构建/部署来“剥离”-beta.0 限定符。但这会生成一个新的提交/githash，尽管代码相同，但会生成一个“新”版本和包。

问题： 人们在生成这些包并在各种环境中测试时如何处理 node/npm 的预发布、测试版和版本？正在使用什么样的 git 工作流程？

我的天真想法：
master 分支将始终为 {current_version)-latest.0、{current_version}-latest.1，并将在 CI 环境中构建/部署以始终运行最新代码。然后，当准备发布 {current_version} 时，创建一个 master 分支并将其命名为类似 BetaRelease/{current_version}.x 的名称。将预发布限定符修改为 beta 而不是 latest。开始构建测试版并部署到 QA 环境中。当 QA 测试/验证、打开错误、开发人员修复并提交回分支时，使用 npm version prerelease 递增。但是，一旦最后一个 beta 版本得到验证/认证，我仍然需要创建一个不包含 beta.0、beta.1 等限定符的包，然后这需要更新版本package.json、重建、新提交和重新部署。该软件包不是 QA 官方测试/认证的软件包。因此，我创建了另一个分支，成为 final 发布分支，名称类似于 Release/{current_version}.x 并去掉 beta 限定符。现在我可以构建这个“纯”{current_version} 包并部署到预生产环境中。

有更好的想法吗？