git blame 仅显示每行最后修改者，不反映演变过程；需用 git log -L 追溯行级变更历史，配合 -C -M 处理重命名，并警惕合并提交干扰。
git blame 不是用来查“谁改过这个文件”，而是查“每一行最后被谁改的”——它不展示历史变更链，只标出最终落笔人。想追溯某行内容怎么一步步变过来的，得换命令。
git blame 基础用法和常见错误现象
直接运行 git blame filename 会按行输出：提交哈希（短格式）、作者、时间、行号、原始代码。但默认不显示完整哈希和可读日期，容易混淆不同分支的同名提交。
- 加
-l显示完整 commit hash，避免哈希冲突误判 - 加
--date short把时间变成2025-03-12格式，比默认的 Unix 时间戳直观得多 - 如果文件刚被重命名或大段复制过，不加
-C -M会导致 blame 把 copied 行标成“新写”，实际作者被掩盖 - 终端里看不到颜色？加
--color-lines（Git 2.25+）能按作者自动染色，一眼识别主力维护者
为什么 git annotate 不是更好选择？
git annotate 是 git blame 的符号链接，不是独立命令——所有参数、行为、帮助页都一模一样。旧教程里写它“更语义化”，只是文字游戏。
Github Stars Analyzer
下载
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 输入
git annotate --help，显示的仍是git blame的文档 - 某些精简版 Git（如 Git for Windows 默认安装）可能压根没建
annotate符号链接，直接报command not found - CI 脚本里混用
annotate容易让新人以为它有特殊能力，其实纯属历史包袱
想看某一行怎么一步步变的？别用 blame
git blame 只回答“最后一笔是谁写的”，不回答“这一行从 if (x > 0) 到 if (x >= 0) 经历了几次修改”。这时候必须切到 git log -L。
-
git log -L 42,42:src/main.py：追踪第 42 行在所有提交中的内容变化（Git 2.19+） -
git log -L :get_user_id:utils.js：用函数名定位（需 Git 2.22+，且函数定义要清晰） - VS Code 中，光标停在目标行 →
Ctrl+Shift+P→ 输入Git: Show Line History，背后就是调用git log -L，带 diff 预览和 commit 消息全文 - IntelliJ IDEA 里右键行号区选
annotate with git blame，只能看到最终作者；要查演变过程，得手动打开 Terminal 执行git log -L
重构后 blame 失效？先确认重命名链路
如果文件被大幅重构（比如拆分成多个、或从 helpers.js 重命名为 core.js），git blame -C -M 仍可能断掉。这时不能只信 blame 输出。
- 用
git log --follow -p filename查重命名历史，确认是否真被 rename 过 - 若发现重命名发生在某次 merge 后，尝试
git blame -C -M -w --ignore-rev=MERGE_COMMIT_HASH filename跳过合并提交干扰 - GitHub / GitLab 网页端点进文件 → 点右上角
Blame→ 点某行右侧的⋯→ 选View earlier revisions，它底层也是走log -L，但 UI 封装得更傻瓜
真正难的不是命令记不住，而是每次看到 blame 结果时，下意识问一句：“这行内容真的只改过这一次吗？”——答案往往是否定的。别跳过 log -L 这步验证。
