全部来自 AI 原创生成并经逐题审校的题目，带 精品 标记的为 AI 复审通过。整卷生成请去组卷。
某仓库的配置文件在主线版本历史 r0→r1→r2→r3→r4 上的变更如下：r0 中三项 (host, port, retries) = (a, 80, 3)；r1 只把 port 改为 8080；r2 只把 retries 改为 5；r3 只把 host 改为 b；r4 只把 port 改为 80。开发者先检出 r2，将 retries 改为 2 后提交得到 r5；随后又检出 r2，将 host 改为 c 后提交得到 r6。若提交时不自动合并其他分支的修改，则 r6 中 (host, port, retries) 依次是？ A. (c, 8080, 2) B. (c, 8080, 5) C. (b, 8080, 5) D. (a, 80, 5)
登录后查看答案
某团队要制定 Git 与 Jira 的使用规范，要求变更可追溯、提交信息格式统一且分支名称可关联需求。以下哪项规范同时满足要求？ A. 每次提交关联 Jira 单号；提交信息采用“单号：动作＋对象”；分支名包含对应单号 B. 每次提交关联 Jira 单号；提交信息可自由填写；分支名使用开发者姓名 C. 仅在版本发布时关联 Jira 单号；提交信息采用“动作＋对象”；分支名使用日期 D. 每次提交关联 Jira 单号；提交信息采用“单号：动作＋对象”；分支名使用任意昵称
某团队要在 Jenkins 中搭建持续集成流水线：检出代码需安装 Git 插件，构建结果上报需安装 Jira 插件，工件归档需安装 Subversion 插件对应的集成组件。管理员查看插件管理页面，已安装插件为：Git Plugin、Subversion Plugin。若 Jenkins 要求每个功能模块必须依赖其专属插件且插件不可跨功能复用，则仍需新安装的插件数量为多少？ A. 0 B. 1 C. 2 D. 3
团队为项目选择配置管理工具时，哪项最应作为选型因素？ A. 工具界面的主色是否符合团队偏好 B. 工具是否适配项目工作流及现有技术环境 C. 工具名称是否容易记忆 D. 工具是否为市场上发布时间最新的产品
某团队使用 Jenkins 管理 Git 仓库，要求每次功能分支或主分支有新提交时自动运行构建与测试，且只有主分支测试通过后才能部署。哪种配置最符合要求？ A. 配置定时构建，并在所有分支的流水线中执行部署 B. 创建多分支流水线并配置仓库 Webhook，在 Jenkinsfile 中仅对主分支执行部署阶段 C. 创建单分支流水线并配置提交后触发，测试通过后对所有分支执行部署 D. 配置人工启动构建，并在 Jenkins 全局设置中指定主分支部署
团队要求每次代码提交都自动执行流水线：先取得本次提交的源码，再编译；单元测试必须使用编译产物；仅当单元测试通过时才打包，且仅当打包成功时才发布制品。下列哪一流程满足全部依赖与门禁要求？ A. 取得源码→编译→单元测试→打包→发布制品 B. 取得源码→单元测试→编译→打包→发布制品 C. 取得源码→编译→打包→单元测试→发布制品 D. 取得源码→编译→单元测试→发布制品→打包
某团队希望每次代码提交后自动完成编译、单元测试并生成构建报告，应优先在持续集成服务器（如 Jenkins）中配置哪种触发机制来启动构建流水线？A. 定时手动启动构建 B. 由版本库 Webhook 在代码提交时自动触发构建 C. 每周手动执行一次构建脚本 D. 由测试人员登录服务器手工点击部署
某团队为微服务项目配置持续集成构建环境。模块 A 和 C 要求 JDK 版本不低于 11，模块 B 要求 JDK 版本不低于 17；同时模块 B 依赖的构建插件要求 Maven 版本不低于 3.8，而 Maven 3.8 又不支持在 JDK 11 下运行该插件，仅在 JDK 17 及以上可正常工作。构建服务器上已安装 JDK 11、JDK 17 和 Maven 3.8.5。若要保证所有模块在同一套构建环境中一次性构建成功，应选择的环境配置是（ ） A. JDK 11 + Maven 3.8.5 B. JDK 17 + Maven 3.8.5 C. JDK 17 + Maven 3.6 D. JDK 11 + Maven 3.6
某仓库提交历史中，main 指向提交 C5，dev 指向 C3；当前 HEAD 处于分离状态并指向 C4。依次执行以下命令： ① git branch alpha ② git switch -c beta ③ git switch dev ④ git switch -c gamma alpha 下列描述正确的是？ A. 最终 HEAD 指向 gamma，且 beta 与 gamma 指向同一提交 B. 最终 HEAD 指向 beta，且 alpha 与 beta 指向同一提交 C. 最终 HEAD 指向 dev，且 alpha 与 dev 指向同一提交 D. 最终 HEAD 指向 alpha，且 gamma 与 dev 指向同一提交
某团队准备上线一个已完成测试的版本。以下哪项流程顺序最符合发布管理要求？ A. 制定发布计划并明确范围→审批发布→部署上线→验证运行状态→记录结果，异常时按预案回滚 B. 部署上线→制定发布计划→审批发布→验证运行状态→记录结果，异常时按预案回滚 C. 制定发布计划并明确范围→部署上线→审批发布→验证运行状态→记录结果，异常时按预案回滚 D. 制定发布计划并明确范围→审批发布→部署上线→异常时先删除回滚记录→验证运行状态
某软件交付包的批准配置清单规定：安装介质为M-7版，部署脚本为S-3版，且两者均须随包交付。物理配置审计检查实际交付物与清单的一致性及完整性。以下哪一份交付包可判定通过该项审计？ A. 含M-7版安装介质和S-3版部署脚本 B. 含M-7版安装介质和S-2版部署脚本 C. 含M-7版安装介质，未提供部署脚本 D. 含M-6版安装介质和S-3版部署脚本
某软件项目交付前开展配置审计，审计员检查以下四项内容：①交付的软件版本所包含的模块是否与合同规定的技术规格一致；②程序代码、目标码与其对应的文档描述是否相互匹配；③源代码中关键算法的实现是否与设计说明所建立的数学模型一致；④用户手册中描述的操作步骤与实际软件界面操作是否一致。依据物理配置审计（PCA）的要点，上述属于物理配置审计的项是：A. ①③ B. ②④ C. ①④ D. ②③
某项目已批准需求规格说明书，随后批准系统设计并将功能分配给软硬件配置项，最终批准完成的产品配置。按基线类型与作用，以下哪项判断正确？ A. 三者依次为功能基线、分配基线、产品基线；基线为后续开发和变更提供受控的参照 B. 三者依次为分配基线、功能基线、产品基线；基线为后续开发和变更提供受控的参照 C. 三者依次为功能基线、产品基线、分配基线；基线为后续开发和变更提供受控的参照 D. 三者依次为功能基线、分配基线、产品基线；建立基线后配置项不得再发生任何变更
某项目在需求评审通过后，将已批准的需求规格说明书配置项集合确立为一个基线。此后开发人员希望修改其中的某条需求，正确的做法是：A. 开发人员可直接修改配置库中的需求文档 B. 提交变更申请，经变更控制流程审批后修改并更新基线 C. 复制一份文档私下修改后再替换原文件 D. 基线一经建立，任何情况下都不得修改 A. 开发人员可直接修改配置库中的需求文档 B. 提交变更申请，经变更控制流程审批后修改并更新基线 C. 复制一份文档私下修改后再替换原文件 D. 基线一经建立，任何情况下都不得修改
某系统的模块依赖关系为：用户管理模块被权限模块调用；权限模块被登录模块和审计模块调用；登录模块被单点登录网关调用。现拟修改用户管理模块的对外接口。按照变更影响分析规则：每个直接受影响模块计2分，每个间接受影响模块计1分。则本次变更的总影响分值为（ ） A. 4分 B. 5分 C. 6分 D. 7分
某版本基线清单记录了需求规格说明书V2、接口定义V3和测试用例V1。仅依据基线与配置项的关系，以下哪项结论正确？ A. 清单中的每个配置项都以其指定版本纳入该基线 B. 每个配置项的所有历史版本都属于该基线 C. 基线是配置项之外的独立文档，与配置项无关 D. 配置项只有纳入基线后才成为配置项
某团队的流程记录显示：变更请求已提交、登记并完成初步筛查，尚未交由变更控制委员会（CCB）作出决定。为使审批建立在对变更后果的评估之上，下一步应做什么？ A. 开展影响分析并形成评估结果 B. 直接实施请求中的变更 C. 验证变更实施结果 D. 关闭该变更请求
某软件项目拟修改日志模块的对外接口。已知该接口被两个上层模块直接调用，且修改后需同步更新相关配置文件。按照变更影响分析的要求，评估该变更时首先应确定的是（ ） A. 修改代码所需的人力成本报价 B. 受该接口变更直接和间接影响的模块范围 C. 项目验收测试的通过标准 D. 变更控制委员会委员的轮换人选
某团队的产品需同时维护多个已发布的长期版本（v1.x、v2.x），且要求：①每个长期版本可独立接收修复；②新功能开发与版本维护严格隔离；③存在明确的开发、发布、热修复等分支角色分工；④每次集成前须经代码评审。该团队不打算采用频繁向单一主干直接集成的轻量流程。据此判断，最不适合该团队需求的分支管理策略是： A. Git Flow B. GitHub Flow C. GitLab Flow（含版本分支） D. 带发布分支的 Git Flow 变体
合并分支时，Git 在文件 report.md 中标出了冲突区域。要完成冲突解决，应采取哪项操作？ A. 手动编辑冲突区域，确定最终内容并删除冲突标记，再暂存文件 B. 保留冲突标记并直接提交合并 C. 删除整个文件并继续合并 D. 使用 git merge --abort 放弃本次合并