HTML结构变更需用语义化commit message驱动：必须用refactor:/feat:/fix:等前缀标识类型，正文明确“改了什么+为什么”，如refactor: replace wrapper divs with semantic <section> and <aside> to improve screen reader navigation，避免模糊动词，确保git log和git blame可追溯真实意图。
HTML结构变更必须靠语义化 commit message 驱动，光靠 git diff 看不出“为什么改”，只有 message 写清楚，才能让后续 git log -p 或 git blame 产生实际价值。
commit message 怎么写才对 HTML 结构变更有效
HTML 文件的修改常涉及语义结构调整（比如把 <div class="header"> 换成 <header>），这类变更不改变功能但影响可访问性和 SEO。如果 message 只写“修复样式”或“调整布局”，三个月后没人知道这行 <main> 是谁加的、为何加。
- 必须包含变更类型前缀：用
refactor:标识结构重写，feat:标识新增语义区块，fix:标识修复 ARIA 属性缺失等可访问性问题 - 正文需说明“改了什么 + 为什么”：例如
refactor: replace wrapper divs with semantic <section> and <aside> to improve screen reader navigation - 避免模糊动词：“优化”“调整”“完善”——换成具体动作：“wrap product list in
<ol>”，“move skip-link before<nav>”
git log -p index.html 为什么有时看不出结构意图
直接运行 git log -p index.html 能看到每次修改的 diff，但若 commit message 空泛，diff 本身无法解释动机。比如删掉一个 <span> 改用 CSS Grid 布局，diff 只显示删除标签，不体现“为移除冗余包裹元素并启用响应式断点”这一设计决策。
- 真实场景：某次提交 diff 显示删了 5 行
<div class="clearfix">，但 message 写的是“clean up”，没人知道这是为适配 CSS containment 还是单纯删 dead code - 补救方法：用
git commit --amend -m "refactor: remove clearfix wrappers, now using display: contents and contain: layout"重写 message（仅限未 push 的本地提交） - 长期建议：在团队中约定 commit template，通过
.gitmessage文件强制格式，避免漏掉关键上下文
怎么用 git blame 定位某段 HTML 结构是谁改的
git blame index.html 会按行显示最后修改者和对应 commit hash，但它依赖 message 是否准确。如果某行 <article> 的 blame 指向一个写“update homepage”的提交，你仍得打开那个 commit 查 message 才知道是不是这次加的语义标签。
立即学习“前端免费学习笔记（深入）”；
- 高效配合方式：先
git blame -L 42,42 index.html定位到具体行，再git show <commit-hash>看完整 diff 和 message - 常见陷阱：编辑器自动格式化（如 Prettier 插入空行或重排属性顺序）会触发整块 blame 变更，导致误判“结构改动”——建议在
.prettierignore中排除 HTML，或统一约定格式化时机 - 注意：blame 不显示被合并进来的修改，若结构变更来自 feature 分支，需加
-M参数检测代码移动：git blame -M index.html
HTML 注释里写 commit ID 有用吗
在 HTML 里硬编码 <!-- commit: a1b2c3d --> 看似直观，但极易过期且无自动化保障。commit hash 会变（rebase 后）、分支会删、message 可能被 amend，而注释不会同步更新。
- 真正可靠的做法：用
git log -n 1 --pretty="%h %s" index.html动态生成版本信息，嵌入构建流程（如用 Hugo 的.GitInfo或 Vite 插件注入） - 手动注释只适合临时标记：比如
<!-- FIXME: this nav needs aria-current, tracked in PR #42 -->，但必须配git add -p确保该注释和修复逻辑一起暂存 - 风险提示：注释暴露 commit ID 可能泄露开发节奏（如高频小提交 vs 少量大提交），生产环境 HTML 应剔除所有开发期注释
结构变更的可追溯性不在 diff 里，在 message 的精度里；不在注释里，在 commit 的上下文里。一旦 message 开始模糊，git log 就退化成翻日志，git blame 就变成查人名——而 HTML 的语义演进，从来不是人名问题，是意图问题。
