代码示例与验证记录

• examples/gitignore-template.txtC/C++ 项目 .gitignore 模板（实测验证）✓ 已实测（git 2.53.0.windows.2 / Windows 11, 2026-08-15）
  编译：复制文件内容为项目根目录的 .gitignore

  适用环境：LinuxWindows(MinGW)macOS

  展开预期输出（实测）

  === .gitignore 生效前（git status --short）===
  ?? build/
  ?? hello.c
  ?? hello.exe
  ?? hello.o
  === 加入 .gitignore 后 ===
  ?? .gitignore
  ?? hello.c
  === 提交后 ===
  （无输出 = 产物已被忽略，工作区干净）
  

  差异说明：本输出为 git 2.53.0.windows.2 / Windows 11 本机实测（实验在系统临时目录进行，结束后已删除）；.o/.exe 由 gcc 15.2.0 编译 hello.c 产生，build/ 为手建目录

  完整源码见 /code 代码示例页

• examples/commit-convention-commands.txt规范提交 + tag 实测序列（feat/fix/docs → v0.1）✓ 已实测（git 2.53.0.windows.2 / Windows 11, 2026-08-15）
  编译：按文件内顺序在终端逐行执行

  适用环境：LinuxWindows(MinGW)macOS

  展开预期输出（实测）

  [main (root-commit) 8aa3215] feat: 添加 hello.c
  [main 19b1a9a] fix: 修正返回值
  [main 433c516] docs: 补充 README
  === git tag ===
  v0.1
  === git log --oneline ===
  433c516 docs: 补充 README
  19b1a9a fix: 修正返回值
  8aa3215 feat: 添加 hello.c
  

  差异说明：哈希值（8aa3215 等）每台机器不同；本输出为 git 2.53.0.windows.2 / Windows 11 本机实测

  完整源码见 /code 代码示例页

• ex-0-3-5-1.下面哪条提交信息最规范？（单选）

  • A.feat: 添加环境检测脚本
  • B.改了一下
  • C.update
  • D.111
  提交本题◌ 未作答

• ex-0-3-5-2.想让 git 忽略项目里的 build 目录，.gitignore 里写哪个最合适？（单选）

  • A.build/
  • B.build
  • C.rm -rf build
  • D.ignore build
  提交本题◌ 未作答

• ex-0-3-5-3.hello.o 之前已被跟踪，加入 *.o 后 git status 仍显示它被修改，原因是？（单选）

  • A.已跟踪文件不受 .gitignore 影响，需 git rm --cached hello.o
  • B..gitignore 文件名写错了
  • C.需要重启电脑
  • D.git 版本太旧不支持 *.o
  提交本题◌ 未作答

章节测验

实践任务

面试问题

• 好的 commit message 有什么标准？团队为什么要统一提交规范？高频C/C++ · easy

  要点：标准：type 前缀 + 一句话说明（feat/fix/docs/refactor 等），第一行简短说清改了什么，需要时正文补充为什么改。统一规范让历史可检索、可回溯、可自动生成发布说明。

  一条好的提交信息回答两个问题：改了什么、为什么改。常见约定（Conventional Commits 风格）： feat（新功能）、fix（修复）、docs（文档）、refactor（重构不改行为）、test、style、chore； 第一行保持在 50 字以内，必要时用空行分隔正文补充动机与影响面。团队统一规范的价值： ① git log 即文档——新成员看历史就能理解演进；② 检索与统计——按前缀过滤 git log --grep=fix 快速定位缺陷修复；③ 自动化——按类型自动生成 CHANGELOG、 判断版本号（fix 升 patch、feat 升 minor）、触发对应流水线；④ code review 效率—— 提交粒度与语义清晰，评审者不用猜。反例是"update""改了一下"，这类信息对回溯毫无价值。

  追问：

  • 追问：一次提交应该包含多少改动？（单一职责：一个提交只做一件事）
  • 追问：refactor 与 fix 怎么区分？（行为不变是重构；行为变化是修复或新功能）

  评分要点：

  • type 前缀与一句话说明
  • 历史可回溯/可检索/可自动化
  • 提交粒度单一职责
• .gitignore 的语法要点有哪些？实际使用中最常见的坑是什么？高频C/C++ · medium

  要点：要点：* 通配、以 / 结尾匹配目录、! 否定、/ 开头锚定根目录。最常见坑：已跟踪文件不受 .gitignore 影响，需要 git rm --cached。

  语法要点：① *.o 这类通配匹配任意层级的同名文件；② build/ 结尾斜杠只匹配目录 （build 不带斜杠则文件目录都匹配）；③ ! 前缀表示否定（重新包含），但父目录已被整体 忽略时子文件无法用 ! 找回，需先放开父目录；④ / 开头把模式锚定到 .gitignore 所在目录。 常见坑：文件已经被 git 跟踪后，再把它写进 .gitignore 不会生效——.gitignore 只作用于 未跟踪文件；要先 git rm --cached <文件> 把它移出跟踪（保留磁盘文件）并提交。 另一个高频问题是把编译产物（.o/.exe/build）长期留在仓库里，导致每次 diff 全是 产物噪音、仓库膨胀；正确做法是建仓第一版就提交 .gitignore。

  追问：

  • 追问：全局 .gitignore 怎么配置？（core.excludesFile，如 ~/.gitignore_global）
  • 追问：如何查看某个文件为什么被忽略？（git check-ignore -v 文件）

  评分要点：

  • 通配/目录/否定/锚定四点
  • 已跟踪文件不受影响的坑
  • 产物入库的工程危害
• git tag 与分支有什么区别？发布版本时一般怎么做？C/C++ · medium

  要点：分支是可移动的指针，随新提交自动前进；tag 是固定在某个提交上的标签，不会移动。发布流程：在要发布的提交上打 tag（如 v1.0.0），必要时推送 tag 到远程。

  从实现看两者都是指向提交的引用（refs/heads/* 与 refs/tags/*），但语义完全不同： 分支是"活"的——在其上继续提交时指针自动向前移动；tag 是"死"的——永远指向打标时的 那次提交，用于标记里程碑（发布版本、验收基线）。tag 分轻量（仅一个指针）与附注 （git tag -a，额外记录打标人、时间、说明与 GPG 签名，发布推荐附注标签）。 发布流程：main 上代码稳定后 git tag -a v1.0.0 -m "发布 1.0.0"，再 git push origin v1.0.0 推送到远程；之后无论代码怎么演进，都能 git checkout v1.0.0 精确回到发布状态。 反例是把 tag 当分支用（在 tag 上继续提交），会破坏"里程碑不可变"的团队共识。

  追问：

  • 追问：tag 打错了怎么办？（git tag -d 本地删除；已推送的需 git push origin :refs/tags/名字）
  • 追问：语义化版本号 v1.2.3 三段分别代表什么？（major.minor.patch）

  评分要点：

  • 可移动与固定的本质区别
  • 轻量/附注两种 tag
  • 发布与回滚场景

内容来源映射