git diff master origin/master 常不准，因 origin/master 仅为上次 fetch 缓存的哈希，非实时远程状态；应改用 @{u} 自动解析上游并校验有效性，或脚本中先 fetch 再 diff。
为什么直接 git diff master origin/master 常常不准
因为 origin/master 不是“远程实时快照”，只是你上次 git fetch 时远端 master 的提交哈希缓存。远端更新后，它不会自动刷新——你看到的差异可能来自几天前的旧状态，甚至报错 fatal: ambiguous argument 'origin/master': unknown revision（说明该引用根本没被拉取过）。
常见现象：
-
git diff master origin/master显示无差异，但git pull确实拉下新提交 -
git show-ref origin/master和git ls-remote origin master输出的哈希不一致
用 @{u} 替代硬编码分支名，避免手动 fetch
@{u}（即 @{upstream}）会自动解析当前分支配置的上游（如 branch.main.remote=origin + branch.main.merge=refs/heads/main），Git 运行时会检查该引用是否有效：若缺失，直接提示你先 git fetch，而不是静默比错。
实操建议：
- 在任意分支下执行
git diff @{u}—— 最省事、最防错 - 不在目标分支时，用
git diff main@{u}显式指定 - Windows / PowerShell 中需加双引号：
git diff "@{u}"
脚本里怎么安全地做一次完整差异检查
写自动化脚本时，不能依赖用户是否提前 fetch，也不能假设 origin/master 存在。必须显式同步再对比。
GitHub Actions Runtime Regression Audit
下载
对比基线与当前 GitHub Actions 运行导出，在 CI 成本和交付周期激增前及时发现工作流或作业运行时性能退化。
推荐脚本逻辑（Bash）：
#!/bin/bash
branch=$(git rev-parse --symbolic-full-name --abbrev-ref HEAD)
git fetch origin "$branch" 2>/dev/null || { echo "fetch failed"; exit 1; }
git diff --name-status "@{u}" 2>/dev/null || {
echo "upstream reference missing — run 'git branch --set-upstream-to=origin/$branch $branch' first"
exit 1
}
关键点：
- 用
git fetch origin "$branch"精准拉取当前分支对应远程引用，不拉全量 - 用
"@{u}"而非origin/$branch，避免分支名拼写错误或 upstream 未设置 - 捕获
git diff失败并给出明确修复指引，而不是让脚本静默失败
比完要什么？别只盯着 git diff
git diff 只告诉你“文件内容变了”，但合并前真正要问的是：“哪些提交还没拉？”“哪些提交还没推？”“有没有漏合？”
对应命令：
- 看本地多了哪些提交（待 push）：
git log @{u}..HEAD - 看远程多了哪些提交（需 pull）：
git log HEAD..@{u} - 看文件变更类型（A/M/D）：
git diff --name-status @{u} - 确认 feature 是否已全量合并进 main：
git log --cherry-pick --left-right main origin/feature/login
容易被忽略的是：两个点 .. 是单向范围，三个点 ... 是对称差集，混用会导致结果完全相反。脚本里一旦写错，就不是“少显示”而是“反着显示”。
