作为我的 CI/CD 管道工作流程的一部分，我正在考虑利用常规提交在 github 中自动生成发布草稿。创建草稿的想法是允许代码所有者在发布之前查看发布说明。
但是，我担心这是否会导致以下两个问题：
- 如果我们继续将每个提交消息创建为常规提交，我们最终会得到一个巨大的更改日志，作为发布草案中的断开信息，这需要在发布之前手动重构以使其具有任何意义
- 我可以想到的替代方法是在所有相关更改完成之前避免提交更改，并在完成后将所有相关更改推送到单个提交消息下。然而，这与 CI/CD 的提议背道而驰，因为它会延迟早期的合并
作为上述问题的解决方案，我正在考虑仅在功能完成后向主线创建拉取请求时才使用常规提交。这样我可以避免发布草案中的所有噪音，同时自动创建发布说明。但我不太确定这是否是正确的方法。我想知道其他人正在采用什么策略来处理这个问题，以及我打算采取的方法是否正确？或者如果我们最好手动创建发行说明？谢谢！