React Native Windows 分支生命周期治理基于 GitHub Actions 的陈旧分支自动清理策略与实践【免费下载链接】react-native-windowsA framework for building native Windows apps with React.项目地址: https://gitcode.com/gh_mirrors/re/react-native-windows导读本指南围绕 react-native-windows 仓库的分支生命周期策略文档展开完整解析仓库如何通过定时 GitHub Actions 工作流自动识别并清理长期无活动的远程分支从而维持分支列表的整洁与可管理。读完本文你将掌握该策略的陈旧判定阈值、受保护分支规则、dry-run 安全机制、手动触发清理的完整操作步骤以及保留分支的三种实战方法并深入理解其底层 cleanup-stale-branches.yml 工作流的每一行实现逻辑。背景为什么 react-native-windows 需要分支生命周期策略react-native-windows 是一个由大量社区开发者共同维护的 React Native Windows 实现仓库。如分支设置指南所述项目要求贡献者先 fork 仓库再提交 PR目的正是保持主仓库分支数量保持在较小的规模——大量开发者在主仓库直接开分支并不具有可扩展性does not scale。然而即便如此主仓库中依然会沉淀出大量实验性、废弃性或长期无人维护的分支。这些陈旧分支会造成几类实际困扰仓库卫生恶化分支列表冗长检索与导航成本上升CI/发布流程干扰如构建流水线文档所示CI 流水线按main、*-stable等分支模式触发无关分支可能带来噪音误用风险开发者可能误以为某陈旧分支仍被维护从而基于过期代码继续开发。为此仓库维护了一套自动化的分支生命周期策略定时扫描所有远程分支标记超过不活动期限的分支并在人工确认后将其删除。该策略的核心实现位于 .github/workflows/cleanup-stale-branches.yml由策略文档完整定义其规则。工作流如何运行定时扫描 手动触发清理工作由 GitHub Actions 中的Cleanup Stale Branches工作流承担其触发方式定义在 cleanup-stale-branches.yml 的on节on: schedule: - cron: 0 8 * * 1 # Every Monday at 08:00 UTC workflow_dispatch: inputs: dry_run: description: List stale branches without deleting type: boolean default: true两种触发方式承担不同职责触发方式频率/时机是否执行删除schedule定时每周一 08:00 UTC否永远为 dry run仅报告workflow_dispatch手动维护者按需触发取决于dry_run输入设为false时真正删除这一定时只报告、删除须人工的设计是整套策略的安全基石自动化流程永不擅自删除分支最终删除动作始终由人类维护者显式确认后发起。工作流还声明了运行所需的最小权限与前置条件permissions: contents: write # 允许删除远程分支并在检出步骤使用fetch-depth: 0拉取完整历史而非浅克隆因为脚本需要读取每个远程分支的提交时间元数据- uses: actions/checkout11d5960a326750d5838078e36cf38b85af677262 # v4.4.0 with: fetch-depth: 0删除分支所需的凭证通过GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}注入环境变量供后续gh命令与git push origin --delete使用。陈旧判定阈值copilot 分支 90 天其他分支 180 天策略对陈旧stale的定义是分支自最后一次提交committerdate起超过阈值天数没有新活动。判定阈值按分支类型区分分支类型陈旧阈值示例copilot/*90 天copilot/fix-xyz、copilot/workspace其他所有分支180 天user/feature、abhi/experiment在工作流实现中阈值与截止时间戳这样计算COPILOT_DAYS90 DEFAULT_DAYS180 COPILOT_CUTOFF$(date -d $COPILOT_DAYS days ago %s) DEFAULT_CUTOFF$(date -d $DEFAULT_DAYS days ago %s)即用date -d N days ago求出两个截止时间戳Unix 秒数。凡分支提交时间早于对应截止时间的即被认定为陈旧。一个值得注意的实现细节是分支最后活动时间的获取方式git branch -r --format%(refname:short) %(committerdate:unix) | while read -r REF DATE; do BRANCH${REF#origin/} [ $BRANCH HEAD ] continue ...使用git branch -r枚举远程分支格式化为短引用名 提交者时间戳两列%(committerdate:unix)取的是提交者日期而非作者日期即最后一次实际提交到远程分支的时间自动排除origin/HEAD这一符号引用避免误判由于前面使用了fetch-depth: 0git branch -r才能拿到各远程分支的完整引用信息。受保护分支永远不被清理的七类模式无论分支存在多久以下分支模式始终被排除在清理范围之外来自策略文档与工作流的PROTECTED正则分支模式说明示例main/master主开发分支maindevelop开发集成分支developrelease/*发布准备分支release/0.80hotfix/*紧急修复分支hotfix/critical-bugarchive/*归档保留分支archive/my-old-branch*-stable稳定版本分支0.72-stable、0.80-stablepreview-*预览版本分支preview-0.80-test这些模式在工作流源码中由一条正则统一表达PROTECTED^(main|master|develop|release/|hotfix/|archive/|[0-9]\.[0-9]-stable|preview-)正则语义逐段解读^main|master精确匹配主分支名release/、hotfix/、archive/按前缀匹配凡以这些目录前缀开头者一律豁免[0-9]\.[0-9]-stable匹配形如0.72-stable、0.80-stable的语义化版本号 -stable后缀分支。这与构建流水线文档中 CI/PR 流水线针对main、*-stable分支触发的工作方式保持一致——稳定分支承载着发布与回归测试职责绝不能被自动清理误删preview-匹配所有预览分支前缀。在扫描循环中受保护判断位于最前面命中后直接跳过echo $BRANCH | grep -qE $PROTECTED continue*-stable与preview-*分支在 FAQ 中被再次强调默认受保护永远不会被删除will never be deleted。额外保护机制存在打开 PR 的分支自动跳过除前缀保护外策略还提供了一道基于 PR 状态的额外防线任何存在打开状态 Pull Request含 Draft 草稿 PR的分支都会被自动跳过无论其年龄多大。这一逻辑通过 GitHub CLI 实现cleanup-stale-branches.yml# Skip branches with open PRs (including drafts) PR_COUNT$(gh pr list --head $BRANCH --state open --json number --jq length 2/dev/null || echo 0) if [ $PR_COUNT -gt 0 ]; then echo [skipped] $BRANCH (has open PR) continue fi要点说明gh pr list --head $BRANCH --state open按分支名查询其名下所有打开的 PRGitHub CLI 默认将草稿 PR 计入 open 状态--json number --jq length仅取 PR 编号数组并求长度比拉取完整 PR 数据更轻量2/dev/null || echo 0即使查询失败也回退为 0保证脚本不会因 API 异常中断判定顺序上PR 检查发生在陈旧性判定之后即只有已陈旧的分支才需要再走 PR 检查未陈旧的分支直接通过。这意味着只要你的分支还挂着一个打开的 PR哪怕只是草稿工作流就绝不会碰它——这为进行中的工作提供了天然的防误删保障。Dry Run 机制定时运行永远只报告不删除整套策略中最重要的安全设计是dry run演练模式。其控制逻辑只有一行cleanup-stale-branches.ymlDRY_RUN${{ github.event_name schedule true || inputs.dry_run }}语义拆解当事件来源是schedule即每周一定时触发时DRY_RUN恒为true无条件执行演练当事件来源是workflow_dispatch手动触发时DRY_RUN取调用者在 Actions 页面上填写的dry_run输入值默认true即默认也是演练。运行日志开头会打印当前参数便于审计echo Stale threshold: copilot/* $COPILOT_DAYS days, others $DEFAULT_DAYS days | Dry run: $DRY_RUN在扫描循环末尾根据DRY_RUN分支处理cleanup-stale-branches.ymlLAST$(date -d $DATE %Y-%m-%d) if [ $DRY_RUN true ]; then echo [stale] $BRANCH (last commit: $LAST) else echo Deleting $BRANCH (last commit: $LAST) git push origin --delete $BRANCH || echo Failed to delete $BRANCH fidry run 时仅输出[stale] 分支名 (last commit: 日期)供维护者审阅实际删除时执行git push origin --delete $BRANCH并用||捕获删除失败的分支例如因保护规则或权限问题打印Failed to delete后继续处理下一个保证单点失败不影响整批清理。如何保留一个分支三种可行方法如果你的分支必须保留到超过陈旧阈值之后策略文档提供了任意一种即可生效的三种方法方法一使用受保护前缀改名为archive/前缀利用archive/*永远豁免的规则将分支移到归档命名空间下。文档给出的完整命令序列为git branch -m my-old-branch archive/my-old-branch git push origin archive/my-old-branch git push origin --delete my-old-branch依次完成本地重命名 → 推送新名字到远端 → 删除远端旧名字。此后该分支以archive/前缀身份获得永久保护同时保留了完整的提交历史。方法二保持一个打开的 PR从你的分支创建一个 PR即使是草稿 Draft PR 也可以。工作流会跳过任何存在打开 PR 的分支。这对于仍在持续推进、只是暂时没有新提交的工作分支尤为实用——草稿 PR 既是工作声明的载体也是防误删的护身符。方法三将分支模式加入工作流的PROTECTED正则如果你所在团队有长期使用的自定义前缀可以向 cleanup-stale-branches.yml 的PROTECTED正则追加该前缀并提交一个 PR 合入仓库。注意这属于全局策略变更会影响所有分支的清理判定应经过维护者评审后再合入。目前仓库中release/*、hotfix/*、archive/*、*-stable、preview-*等模式正是通过这一机制获得豁免的。手动清理维护者触发删除的完整步骤按照策略文档的 Manual Cleanup 章节维护者执行实际删除的操作为进入仓库Actions标签页选择Cleanup Stale Branches工作流点击Run workflow在弹出的输入框中将dry_run设为false运行后工作流会遍历所有陈旧分支并执行git push origin --delete同时打印Deleting branch (last commit: date)日志。建议的操作顺序是先以默认的dry_runtrue运行一次从日志中确认待删分支清单无误关注[stale]行确认后再以dry_runfalse正式执行。这与定时任务只报告的设计互为呼应形成先审后删的双保险。常见问题FAQ解读策略文档收录了三个高频问题其答案直接反映了策略边界Q分支被误删了怎么办AGitHub 上的分支删除在短期内是可恢复的GitHub 提供删除后恢复功能也可以从本地克隆中恢复。同时由于定时任务永远只执行 dry run实际删除必然经过人工触发误删窗口被大幅压缩。Q会删除有打开 PR 的分支吗A不会。工作流会检查分支名下是否存在打开状态的 PR含草稿存在则跳过。Q稳定版和预览分支会受影响吗A所有*-stable和preview-*分支默认受保护永远不会被删除。这一设计保证了已发布版本的维护分支如0.72-stable、0.80-stable与预览迭代分支的安全。完整执行流程一览综合以上分析Cleanup Stale Branches工作流每次运行无论定时还是手动都遵循如下判定流水线枚举全部远程分支git branch -r --format... │ ├─ 是 origin/HEAD──────────────→ 跳过 ├─ 匹配 PROTECTED 正则──────────→ 跳过main/master/develop/release//hotfix//archive//*-stable/preview-* ├─ 未超过陈旧阈值copilot 90 天 / 其他 180 天→ 跳过分支仍然活跃 ├─ 存在打开 PR含草稿────────→ 跳过打印 [skipped] ... has open PR │ └─ 标记为 [stale] ├─ dry_runtrue → 仅打印 [stale] 分支名与最后提交日期 └─ dry_runfalse → git push origin --delete 实际删除这套流程将枚举 → 豁免判定 → 陈旧判定 → PR 保护 → 演练/执行五步解耦逻辑清晰、每步都有日志输出便于维护者审计每一次清理动作。延伸阅读分支生命周期策略文档本文所依据的官方策略定义cleanup-stale-branches.yml策略的完整工作流实现分支设置指南fork、upstream 与分支管理规范解释了主仓库保持少量分支的设计动机构建流水线文档展示*-stable等分支在 CI/PR 流水线中的实际触发角色.github/workflows/README.md仓库其他 GitHub Actions 工作流如 cherry-pick、Dependabot 触发的说明.github/copilot-instructions.md仓库对 Copilot 生成分支copilot/*类的卫生约定与 90 天短阈值的策略背景相呼应。【免费下载链接】react-native-windowsA framework for building native Windows apps with React.项目地址: https://gitcode.com/gh_mirrors/re/react-native-windows创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考