如何结合Pull Request工作流使用Github Releases？能否固定Master代码基线

刚好之前帮团队折腾过类似的流程，给你梳理一下清晰的操作路径，完全适配你们现有的PR工作流：

核心结论先给你拍板 #

GitHub Releases完全可以留存某一时刻Master仓库的代码副本，而且绝对不会受后续PR合并的影响——因为它本质是基于Git标签（Tag）创建的不可变代码快照，标签绑定的是特定提交的哈希值，后续Master分支再怎么更新，这个快照都会原封不动地保留。

结合你们PR工作流的具体操作步骤 #

假设你们已经完成了所有要发布的功能PR合并，Master分支处于待发布的稳定状态：

• 给Master的当前提交打一个固定标签
  标签建议用语义化版本号（比如v1.0.0、v2.1.3），方便后续识别。可以用命令行操作：

  # 先拉取主仓库最新的Master，确保本地和远程一致
  git fetch upstream
  git checkout master
  git merge upstream/master
  
  # 创建带注释的标签（-a是创建注释标签，-m是标签说明）
  git tag -a v1.0.0 -m "正式发布版本1.0.0：新增XX功能，修复XX问题"
  
  # 把标签推送到主仓库（注意不是你自己的Fork，是团队的主仓库）
  git push upstream v1.0.0
  

  也可以直接在GitHub主仓库的网页上操作：进入仓库主页→点击右侧的"Releases"→点击"Tags"→点击"Create a new tag"，填写标签名和说明后保存。

• 基于标签创建GitHub Release

  • 进入主仓库的Releases页面，点击"Draft a new release"
  • 在"Choose a tag"下拉框里选择刚才创建的标签（比如v1.0.0）
  • 填写版本标题（比如「Version 1.0.0 正式发布」）和发布说明：这里可以列出本次发布包含的所有PR、新增功能、Bug修复，GitHub还提供了「Generate release notes」按钮，能自动帮你生成这段内容，非常省心
  • 根据需求选择是否标记为「Pre-release」（预发布版本），如果是正式发布就留空
  • 点击「Publish release」，完成发布

为什么这个快照不会受后续PR影响？ #

Git标签是指向特定提交的固定指针，不像分支（比如Master）会随着新提交移动。当你后续合并新的PR到Master时，Master的HEAD会指向新的提交，但之前打标签的那个提交哈希值不会变，对应的代码快照会一直保存在GitHub上——你随时可以回到Releases页面下载该版本的源码包，或者基于这个标签创建分支做补丁维护。

适配你们工作流的小建议 #

• 发布前一定要确保Master分支是最终的稳定状态：所有要包含的PR都已合并，没有未解决的Bug
• 如果之后需要给这个发布版本打补丁，可以基于标签创建一个维护分支（比如release/v1.0.x），后续的补丁PR直接合并到这个维护分支，这样不会干扰主分支（Master）的新功能迭代
• 可以把打标签、创建Release的步骤加入团队的发布 checklist，确保每个版本都有对应的快照留存

内容的提问来源于stack exchange，提问作者VAAA