我正在寻求有关GitHub上与问题系统相关的适当工作流程的建议。
当前，我有一个master分支，该分支始终仅包含发行的软件（带有发行号的标签）。我维护一个changes分支（应该称为tobereleased，所以在这里我将使用该名称）。执行释放时，tobereleased与master相匹配。所有功能都是在tobereleased的分支上完成的，并且每个功能完成后，它会合并到tobereleased中（实际上，tobereleased会快速转发到功能分支的尖端，因为所有功能分支将重新建立到新的tobereleased分支），然后继续工作。
我使用GitHub的问题系统输入问题，并在提交消息中输入问题解决方案。我注意到这些提交消息出现在问题线程中，但问题仍然存在。仅当我执行发布时，问题的问题才会自动解决，因为解决问题的代码将合并到master分支中。
当我查看这些问题时，很难不看一眼就知道实际上已解决的问题-我什至不确定如何对此进行过滤。
我正在考虑如下更改工作流程：
master是tobereleased分支，但实际发行版带有其发行版号以及发行版和PyPI上发行版的zip标签。master与压缩版本有所不同（出于某种原因，我认为这是个坏主意）。这样，拉下master分支就变成了拉下“ beta”版本-毕竟，分支上的所有内容都是tobereleased，并且已经过测试。无论如何，压缩的发行版都在那里。
此外，通过这种方式，问题将显示为已关闭。如果有人遇到了问题，但实际上已经发布了代码，那么他们会知道尝试使用master上的“ beta”版本。
在我看来，这就是GitHub运作的方式。有人对此有任何建议吗？
还有一件事，显示的提交统计信息也仅在master分支中可见-再次证明我应该按照我的建议去做。