我发现了semantic-release，它看起来非常有用。但是我想知道如何自定义它以适合我们的工作流程：
这是一个私人行业项目，因此我们不能完全精益求精，必须在发布产品之前遵守内部设计指南，包括分阶段进行批量PR。
我可以添加一个dev分支，并从dev推送暂存，然后在将dev合并到master之后从master推送生产。 但是我希望我的github草案版本在拉取请求被合并回dev后立即进行更新（草案版本一旦将dev合并到master中，它将成为最新版本）。
这有可能吗？我最近安装了语义请求请求github应用程序，并开始使用常规的提交约定，但是我不清楚如何单独使用release-notes-generator还是是否可以处理github草稿发布模式。
答案 0 :(得分：0)
但是我想知道如何自定义它以适合我们的工作流程：*没有开发分支，只有master和feature / fix / chore分支。 *最新版本（带有相关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）。
但是我不清楚如何单独使用release-notes-generator，或者它是否处理github草稿的发布模式
release-notes-generator负责生成发行说明，并且不与GitHub交互。 @semantic-release/github负责在GitHub上创建发布。