# 1. Git Flow（Vincent Driessen）的双主干（master、develop）与多特性（feature、release、hotfix）的策略 A feature 分支从 master 直接拉出 B master 保存稳定可发布版本，develop 是日常集成分支 ✓ 正确答案 C hotfix 分支从 develop 拉出 D release 分支从 master 拉出
# 2. GitHub Flow 的简化策略中 master + feature branch + PR 的轻量级 A 需要 develop 与 release 长期分支 B 只有一条长期主干 master，用短命 feature 分支 + PR 合并 ✓ 正确答案 C 不使用 PR 评审 D master 不保证可部署
# 3. GitLab Flow 的"环境分支"（environment branch）中 pre-production、production A 环境分支与部署无关 B 环境分支从 master 无条件拉出 C 只有一个 production 分支即可 D 每个部署环境对应一个分支，合并到环境分支即触发对应部署 ✓ 正确答案
# 4. Trunk-Based Development（主干开发）的 PR 短小与高频率合并 A 强调短小 PR 与高频率合并，配合 feature flag 保证主干始终可部署 ✓ 正确答案 B 合并后主干不保证可部署 C 依赖长期特性分支 D 不需要 CI/CD 支撑
# 5. 分支的"保护规则"（branch protection）中 required reviewers、required status checks A 保护规则只用于开发分支 B required status checks 与 CI 无关 C required reviewers 与 required status checks 分别强制人工评审与自动化检查通过后才能合并 ✓ 正确答案 D 保护规则禁止所有合并
# 6. 分支的"命名规范"（naming）中 feature/、bugfix/、release/、hotfix/ 的工程价值 A 命名规范没有任何价值 B 命名规范是平台强制规则 C 前缀只影响可读性，不影响 CI D 用前缀表达分支意图，便于可读性与 CI 按前缀分流 ✓ 正确答案
# 7. 分支策略的"长期分支"（long-lived branch）vs"短期分支"（short-lived）的工程取舍 A 长期分支隔离性好但集成成本高，短期分支冲突少但需要强 CI ✓ 正确答案 B 长期分支永远优于短期分支 C 短期分支必然产生大量冲突 D 两者取舍与 CI 无关
# 8. Git LFS 大文件管理的适用边界中二进制资产（模型、媒体）vs 源码，LFS 指针与配额成本 A LFS 适合所有源码文件 B LFS 指针存储文件真实内容 C LFS 适合二进制资产，源码等文本应留在常规 git ✓ 正确答案 D LFS 无配额成本限制
# 9. Git Flow 的适用场景中版本化产品（桌面应用、移动 App） A 只适合持续部署的 SaaS B 适合版本化产品，如桌面应用、移动 App，需要维护多版本线 ✓ 正确答案 C 与版本号无关 D 无法管理已发布版本的 hotfix
# 10. GitHub Flow 的适用场景中 SaaS 持续部署 A master 不用于部署 B 只适合桌面应用 C 需要 develop 与 release 分支 D 适合 SaaS 持续部署，master 合并即部署 ✓ 正确答案
# 11. GitLab Flow 的适用场景中多环境的 SaaS A 不支持多环境部署 B 只适合桌面应用 C 与 GitHub Flow 完全等价 D 适合多环境 SaaS，用环境分支表达部署状态 ✓ 正确答案
# 12. Trunk-Based Development 的适用场景中成熟 CI/CD 的 SaaS A 适合 CI/CD 不成熟的团队 B 需要长期分支配合 C 无需 feature flag D 适合 CI/CD 成熟、自动化测试充分的 SaaS 团队 ✓ 正确答案
# 13. 分支策略与 CI/CD 集成的程度 A 分支策略与 CI/CD 完全无关 B 轻量分支策略依赖高集成度的 CI/CD 保证主干可部署 ✓ 正确答案 C 集成程度不影响质量 D 重分支策略不需要 CI/CD
# 14. 分支策略与发布节奏（release cadence）的对齐 A 低频发布适合 GitHub Flow B 发布节奏与分支策略无关 C 高频发布适合 Git Flow D 高频发布适合轻量分支策略，低频发布适合带 release 分支的模型 ✓ 正确答案
# 15. 分支策略与团队规模（team size）的适配 A 团队规模对分支策略无影响 B 大团队适合无保护规则 C 小团队适合轻量分支策略，大团队需要更强的流程约束 ✓ 正确答案 D 小团队必须用 Git Flow
# 16. monorepo 的 sparse checkout 与 partial clone（--filter=blob:none）降低检出体积 A 两者都只减少元数据 B partial clone 保留全部 blob C sparse checkout 无法用于 monorepo D sparse checkout 减少工作区文件，partial clone 延迟下载 blob 减少仓库体积 ✓ 正确答案
# 17. .gitattributes 规范化换行符（CRLF/LF）与自定义合并驱动（merge driver）配置 A .gitattributes 只能控制换行符 B 换行符规范与合并驱动无关 C 可用 text/eol 属性规范化换行符，用 merge 属性配置自定义合并驱动 ✓ 正确答案 D .gitattributes 不影响 git 行为
# 18. Git rebase vs merge 的工程取舍中线性历史 vs 完整历史的可读性 A merge 生成线性历史 B rebase 不改变提交历史 C merge 保留完整拓扑历史，rebase 生成线性历史但会重写提交 ✓ 正确答案 D 两者对历史完全无影响
# 19. Interactive rebase（交互式变基）的工程应用中 squash、reword、reorder、drop A 只能用于已共享的分支 B 只能新增提交 C 不改变提交历史 D 用 squash/reword/reorder/drop 等操作整理提交历史 ✓ 正确答案
# 20. Rerere（reuse recorded resolution）中重用冲突解决方案的工程价值 A 记录并复用已解决的冲突方案，减少重复解决冲突 ✓ 正确答案 B 只能用于 merge 不能用于 rebase C 自动生成冲突 D 默认总是启用
# 21. git rebase --onto 的高级变基中从分支树中"嫁接"提交 A 把指定范围的提交移植到新的基线上，实现分支"嫁接" ✓ 正确答案 B 与普通 rebase 完全相同 C 只能删除提交 D 只能重放到原基础上游
# 22. 冲突（merge conflict）的解决策略中 3-way merge、recursive merge、union merge A 3-way merge 基于共同祖先三方比较，recursive merge 在多个祖先时递归合并形成虚拟基 ✓ 正确答案 B 3-way merge 不基于共同祖先 C union merge 必然产生冲突 D recursive merge 无法处理多祖先
# 23. 冲突的"预防"（prevent）中小 PR、频繁同步、单向所有权 A 冲突是无法预防的 B 单向所有权与冲突无关 C 只有事后解决这一种手段 D 通过小 PR、频繁同步、单向所有权降低冲突发生概率 ✓ 正确答案
# 24. rebase 的"恢复"（recovery）中 reflog 找回丢失的 commit A rebase 后提交必然永久丢失 B reflog 无法用于恢复 C 恢复不受 GC 影响 D reflog 记录引用历史，可在提交未被 GC 前找回 ✓ 正确答案
# 25. Trunk-Based Development 下"评审仍必需"如何与"短命分支/直接提交主干"调和，用 feature flag 遮蔽未完成代码 A TBD 下不需要评审 B 用 feature flag 遮蔽未完成功能，使小改动可安全合入主干且评审聚焦于小改动 ✓ 正确答案 C 未完成代码不能合入主干 D feature flag 与评审无关
# 26. GitFlow 的 release 分支与 hotfix 分支在评审责任上的差异中紧急修复由谁批准、如何事后补审 A hotfix 紧急时可快速放行，但需事后补审以弥补质量把关 ✓ 正确答案 B hotfix 与 release 评审流程完全相同 C hotfix 无需任何批准 D release 分支无需评审
# 27. Conventional Commits 的 type（feat/fix/refactor）如何驱动自动 CHANGELOG 与语义化版本，减少评审中对"这是什么变更"的追问 A type 驱动自动版本与 CHANGELOG，减少评审中"变更是什么"的追问 ✓ 正确答案 B type 与评审无关 C type 只影响提交显示 D 所有 type 都触发 MAJOR
# 28. 提交粒度（commit granularity）对评审可回溯性的影响中一个逻辑变更一个提交 vs 难以二分定位的巨型提交 A 巨型提交更利于回溯 B 提交粒度与可回溯性无关 C 一个逻辑变更一个提交便于评审、bisect 与 cherry-pick ✓ 正确答案 D 提交越碎越好
# 29. rebase 的"自动"（autosquash）中 fixup! 与 squash! 前缀的自动处理 A 自动把 fixup!/squash! 前缀提交归位到对应原提交并合并 ✓ 正确答案 B autosquash 无法在 rebase 中使用 C autosquash 会删除所有提交 D fixup! 与 squash! 效果完全相同
# 30. rebase 的"黄金法则"（golden rule）中不要 rebase 共享分支 A 共享分支也应使用 rebase B 可以随意 rebase 任何分支 C rebase 不改变提交 SHA D 不要 rebase 已共享的分支，因为重写历史会破坏他人的工作 ✓ 正确答案
# 31. Conventional Commits 的 BREAKING CHANGE 脚注触发 major 版本与评审加强机制 A BREAKING CHANGE 只触发 PATCH B BREAKING CHANGE 触发 MAJOR 升级，并应触发更强评审与迁移说明 ✓ 正确答案 C BREAKING CHANGE 无需额外评审 D BREAKING CHANGE 与评审无关
# 32. 分支策略与评审 SLA 的耦合中长期分支为何天然积累难以评审的大 diff A 长期分支 diff 更小评审更容易 B 分支寿命与评审无关 C 短命分支必然难以评审 D 长期分支积累大 diff，使评审困难且拖慢合并，形成恶性循环 ✓ 正确答案
# 33. "原子提交"（atomic commit）原则中每个提交可独立编译、测试通过，便于逐提交评审与 git bisect A 每个提交应可独立编译、测试通过，便于评审与 git bisect ✓ 正确答案 B 原子提交与 bisect 无关 C 原子提交只需保持消息规范 D 原子提交允许中间态不可构建
# 34. 提交消息正文（body）说明"为什么"而非复述"做了什么"的评审与考古价值 A body 与历史回溯无关 B body 应复述 diff 内容 C body 只对工具重要，对评审无价值 D body 应说明"为什么"做的动机与权衡，而非复述"做了什么" ✓ 正确答案
