# 1. git merge 与 git rebase 的选择决策中团队协作分支与个人特性分支分别适用哪种？黄金法则是什么？ A 共享分支用 merge，个人特性分支可用 rebase，黄金法则是不 rebase 已共享分支 ✓ 正确答案 B 所有分支都应 rebase C merge 会重写历史 D rebase 不改变提交 SHA
# 2. Interactive Rebase 工作流中如何用 `git rebase -i` 进行 squash、reword、reorder、split 操作整理提交历史？autosquash 与 fixup 的配合使用？ A interactive rebase 只能删除提交 B autosquash 无法配合 fixup C 用 squash/reword/reorder/split 等操作整理，autosquash 自动归位 fixup!/squash! 提交 ✓ 正确答案 D split 不需要 edit 操作
# 3. git bisect 定位回归缺陷的完整流程中如何设定 good/bad 边界、自动化 bisect run 脚本、处理不可构建的中间提交（skip）？ A bisect 只能手工逐个测试 B bisect skip 会终止定位 C 设定 good/bad 边界后用二分定位，可用 bisect run 自动化、bisect skip 跳过不可构建提交 ✓ 正确答案 D bisect 无法处理不可构建提交
# 4. git reflog 的「时间旅行」恢复中误删分支、错误 reset --hard、rebase 中断后如何用 reflog 找回提交并重建分支，恢复的边界是什么？ A 可用 reflog 找回误删分支、错误 reset、rebase 中断的提交，前提是提交未被 GC ✓ 正确答案 B reflog 只能恢复 reset C 提交被 GC 后 reflog 仍能恢复 D reflog 无法重建分支
# 5. git cherry-pick 与 git revert 的典型使用场景中热修复回合入主干与撤销已发布提交？ A revert 会重写历史 B cherry-pick 撤销已发布提交 C cherry-pick 复制提交改动，revert 生成反向提交撤销已发布提交 ✓ 正确答案 D 两者功能相同
# 6. 误提交敏感信息（密钥）后的正确处置流程中为什么仅 revert 不够，需要 filter-repo + 轮换密钥？ A revert 即可彻底删除密钥 B filter-repo 无需配合密钥轮换 C 仅 revert 不够，因为密钥仍在历史中，必须先轮换密钥再用 filter-repo 清理 ✓ 正确答案 D 误提交密钥没有风险
# 7. cherry-pick vs rebase 的选择中何时用 cherry-pick 精确摘取单个提交？cherry-pick 导致的重复提交和冲突如何处理？ A 精确摘取单个提交用 cherry-pick，整体平移分支用 rebase，cherry-pick 可能产生重复提交 ✓ 正确答案 B rebase 用于摘取单个提交 C cherry-pick 不会产生重复提交 D cherry-pick 用于整体平移
# 8. git worktree 并行开发中如何在不 clone 的情况下同时检出多个分支进行开发/测试/hotfix？worktree 的生命周期管理和常见陷阱？ A worktree 无需清理 B worktree 需要额外 clone 仓库 C 同一分支可被多个 worktree 同时检出 D 可在同一仓库下为多个分支创建独立工作区并行开发，需用 add/remove/prune 管理生命周期 ✓ 正确答案
# 9. .gitignore 的边界中已跟踪文件（tracked file）为何不受 .gitignore 影响，如何强制忽略与恢复跟踪？ A .gitignore 对所有文件生效 B 已跟踪文件不受影响的说法错误 C .gitignore 只对未跟踪文件生效，已跟踪文件需先 git rm --cached 再忽略 ✓ 正确答案 D 无法强制忽略已跟踪文件
# 10. Git 的工作区、暂存区与版本库（working tree / index / object store）三层模型中 git add / reset 在各层之间的移动语义？ A reset 只影响工作区 B add 把内容写入版本库 C add 把工作区写入暂存区，reset --hard 同时重置 HEAD、暂存区与工作区 ✓ 正确答案 D reset --soft 会丢弃工作区改动
# 11. git log --graph 与分支可视化中--graph、--oneline、--all 组合如何快速理解仓库拓扑与合并历史？ A --graph 只显示一条直线 B --all 只显示当前分支 C --oneline 显示完整 diff D 组合可图形化展示分支分叉与合并历史，快速理解仓库拓扑 ✓ 正确答案
# 12. git submodule 与 git subtree 的取舍中外部依赖锁定、更新流程与团队协作的差异？ A subtree 需要额外 init 命令 B submodule clone 即完整 C submodule 用指针锁定子仓库版本，subtree 把子仓库历史并入主仓库 ✓ 正确答案 D 两者机制完全相同
# 13. 大规模仓库的 Git 性能方案中浅克隆（shallow clone）、部分克隆（partial clone）、稀疏检出（sparse checkout）在 monorepo 中的适用边界与团队协作影响？ A 三者都对历史无影响 B 稀疏检出增加仓库体积 C 浅克隆保留完整历史 D 浅克隆减少历史体积、部分克隆延迟下载 blob、稀疏检出减少工作区，可组合使用 ✓ 正确答案
# 14. git stash、reflog、bisect 三个"救急"命令的典型场景？ A stash 用于定位回归 B stash 临时保存未提交改动，reflog 恢复误操作，bisect 二分定位回归 ✓ 正确答案 C reflog 用于临时保存改动 D bisect 用于恢复误删分支
# 15. Git 提交签名（GPG/SSH）的配置与验证中如何配置 commit signing？GitHub/GitLab 的 verified badge 机制？SSH signing 相比 GPG 的便利性？ A verified badge 与签名无关 B SSH signing 需要额外生成 GPG 密钥 C 签名只影响提交消息 D 配置签名 key 后提交自动签名，GitHub/GitLab 显示 verified badge，SSH signing 复用现有 SSH 密钥更简便 ✓ 正确答案
# 16. git config 的 core.autocrlf / core.eol 与 .gitattributes 的协同中跨平台换行符（CRLF/LF）规范化的优先级？ A .gitattributes 的 text/eol 规则优先级高于本地 core.autocrlf/core.eol，保证跨平台一致 ✓ 正确答案 B 本地 config 优先级高于 .gitattributes C .gitattributes 无法控制换行符 D 换行符与跨平台协作无关
# 17. GitLab CI 的 extends/include 复用机制，与 Git 分支/标签规则结合定义多环境流水线？ A extends 用于合并外部文件 B include 合并外部配置，extends 继承 job 配置，二者结合 rules 可按分支/tag 定义多环境流水线 ✓ 正确答案 C include 用于 job 继承 D rules 无法按分支分流
