如何确保GitHub/Gitea发布制品仅包含目标里程碑的PR？

一、确保发布制品仅含目标里程碑PR的实现方式 #

以下是实际项目中常用的三种落地方案：

• 基于分支的版本隔离策略
  提前为每个对应里程碑的版本创建独立的发布分支，比如release/1.3.0。所有分配到1.3.0里程碑的PR直接合并到该发布分支，而非master分支；master分支仅合并未来版本（如1.4.0、1.5.0）的PR。发布时直接从对应发布分支构建制品，天然保证只包含该里程碑的PR。若需回溯bugfix到旧版本（如1.1.3-backport），则从对应旧发布分支切回溯分支，合并后发布即可。
• Cherry-Pick + 临时发布分支方案
  若必须保持master为统一主分支（所有PR先合入master），发布前按以下步骤操作：
  1. 从master的上一个正式版本tag节点切出临时发布分支temp-release/1.3.0
  2. 通过平台的里程碑筛选功能导出1.3.0里程碑下的所有PR，提取每个PR对应的merge commit哈希
  3. 逐个将这些commit cherry-pick到临时分支，处理可能的冲突
  4. 测试通过后，基于该临时分支打tag并生成发布制品
• 自动化工具辅助筛选
  利用CI/CD工具（如Gitea Actions、Jenkins）结合平台API，自动完成筛选和构建：通过API获取目标里程碑的所有PR，提取对应commit，批量cherry-pick到临时分支后直接触发构建流程，全程无需手动操作。

二、处理PR依赖未发布里程碑代码的情况 #

这种问题优先从流程上规避，无法规避时再用技术手段补救：

• 前置流程规避：严格的里程碑分配规则
  制定明确的PR提交规范：若PR A依赖PR B，PR B的里程碑必须早于或等于PR A的里程碑。例如1.3.0的PR不能依赖1.4.0的PR，否则要么将PR B调整到1.3.0里程碑，要么将PR A推迟到1.4.0。代码评审环节必须检查依赖的里程碑合规性，不符合要求的直接打回。
• 技术补救：回溯最小依赖代码
  若已出现依赖且无法调整里程碑，需将依赖的PR中仅解决当前依赖的最小代码块cherry-pick到目标版本的发布分支/临时分支。注意必须评估该代码的影响，确保不会引入未发布版本的其他特性，仅解决依赖问题。若依赖代码无法拆分，则需同步cherry-pick所有必要的关联commit。
• 紧急修复：临时补丁分支
  若依赖代码无法拆分且目标版本必须紧急发布，可从master分支切出包含依赖代码的临时补丁分支，手动移除未发布版本的无关特性后，合并到目标版本的发布分支构建发布。发布完成后，需将该补丁同步回master分支，避免后续版本出现代码不一致。

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