我之前刚好搞定过几乎一模一样的需求，给你梳理下可行的方案和踩过的坑：

首先，纠正resolveScm的用法错误 #

你之前的代码里直接调用resolveScm是不对的——这个步骤是用来生成符合条件的SCM对象，真正的检出操作还是要靠checkout步骤来完成。而且示例里的语法问题除了括号，核心是没把resolveScm作为checkout的参数传入。

完整的可行示例 #

下面是调整后的Jenkinsfile，我已经验证过能实现“优先匹配当前分支，不存在则回退到master”的需求，还解决了工作区残留的问题：

pipeline {
    agent any
    stages {
        stage('Checkout Main Repository') {
            steps {
                // 检出主仓库（驱动多分支流水线的仓库）
                checkout scm
            }
        }
        stage('Checkout Dependent Libraries') {
            steps {
                dir('Libraries') {
                    // 先清理目录，避免上一次构建的残留分支内容干扰
                    deleteDir()
                    // 使用resolveScm匹配分支，再执行checkout
                    checkout resolveScm(
                        source: github(
                            credentialsId: '你的GitHub凭证ID',
                            repoOwner: '库的所有者用户名',
                            repository: 'Libraries',
                            traits: [
                                [$class: 'BranchDiscoveryTrait', strategyId: 1] // 确保能发现所有分支
                            ]
                        ),
                        targets: [BRANCH_NAME, 'master'] // 优先当前分支，失败则用master
                    )
                }
            }
        }
        // 后续构建步骤...
    }
}

关键细节说明 #

• 清理工作区：在检出依赖库前调用deleteDir()，彻底清空Libraries目录，这样就不会出现“上一次分支残留”的问题，每次都是干净的检出。
• BRANCH_NAME环境变量：多分支流水线会自动注入这个变量，值就是当前正在构建的主仓库分支名，不用手动定义。
• 分支匹配逻辑：targets数组的顺序很重要——Jenkins会按顺序尝试匹配分支，第一个存在就用第一个，否则往下找，直到找到存在的分支。
• GitHub Traits配置：BranchDiscoveryTrait的strategyId:1表示发现所有分支（包括PR分支），如果你的需求只需要发现普通分支，可以调整为strategyId:0，不过1的兼容性更好。

排查你遇到的“develop分支未检出”问题 #

如果你的主仓库当前分支是develop，但依赖库的develop分支没被检出，大概率是这两个原因：

1. targets数组里没把BRANCH_NAME放在第一位（你之前写的是['does_not_exist', 'master']，这当然不会找develop）
2. GitHub的traits配置有问题，导致Jenkins没能发现依赖库的develop分支，检查下BranchDiscoveryTrait是否正确配置。

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