我发现了语义发布，它看起来非常有用。但是我想知道如何自定义它以适应我们的工作流程：
- 没有开发分支，只有一个主分支和功能/修复/家务分支。
- 最新版本(带有相关 git 标记的 GitHub(对应于推送到生产环境的版本。
- 草稿版本对应于推送到暂存的版本。
这是一个私营行业项目，因此我们不能完全精益，必须尊重内部设计准则，包括在生产发布之前在暂存时批量 PR。
我可以添加一个 dev 分支，并在将 dev 合并到主节点后从 master 推送暂存，然后从 master 推送生产。 但是我希望我的 github 草稿版本在拉取请求合并回 dev 后立即更新(一旦 dev 合并到 master 中，该版本将成为最新版本的草稿版本(。
这在某种程度上可能吗？我最近安装了语义拉取请求 github 应用程序，并开始使用传统的提交约定，但我不清楚如何单独使用发行说明生成器，或者它是否处理 github 草稿发布模式。
但是我想知道如何自定义它以适应我们的工作流程： * 没有开发分支，只有一个主分支和功能/修复/家务分支。 * 最新版本(带有相关 git 标签的 GitHub(对应于推送到生产的版本。 * 草稿版本对应于推送到暂存的版本。
它仅分析您配置的分支上的提交(默认为master(。提交如何到达那里并不重要，您可以在它们到达master之前将它们合并到您想要的任何分支中。当他们进入master和语义发布运行时，它将分析master上的提交，并在必要时进行发布。
语义发布尚不支持草稿/预发布(请参阅 https://github.com/semantic-release/semantic-release/issues/563(。
我最近安装了语义拉取请求 github 应用程序
你指的是什么？此时没有语义发布 GitHub 应用程序，即使计划在某个时候(https://github.com/semantic-release/semantic-release/issues/585(有一个。
但我不清楚如何单独使用发行说明生成器，或者它是否处理 github 草稿发布模式
release-notes-generator负责生成发行说明，不与 GitHub 交互。@semantic-release/github 负责在 GitHub 上创建发布。