用git rev-parse --show-toplevel命令可准确判断当前目录是否为git仓库根目录：若返回路径则为根目录，否则报错；该命令基于git内部逻辑，比检查.git目录更可靠。
当前目录到底是不是仓库根？
别凭感觉判断，pwd 输出的路径才是真实依据。很多人在 src/ 或 backend/ 里敲 git status，但 .git 其实在上两级。用 git rev-parse --show-toplevel 最直接：它只在合法仓库中返回根路径，否则报错 —— 这个命令比 ls -la | grep .git 更可靠，因为它走的是 Git 内部查找逻辑。
.git 目录是否存在或损坏？
.git 是隐藏目录，ls 默认看不见，必须加 -a；Windows 资源管理器需手动开启“显示隐藏的项目”。但存在不等于可用：
-
cat .git/config看是否可读、格式正常（比如有没有空文件或乱码） -
cat .git/HEAD必须是类似ref: refs/heads/main或一个 40 位哈希，空文件或非法内容会导致同样报错 - 如果
.git被重命名为.git-disabled（某些 IDE 或脚本会干这事），直接改回来就行，不用git init
git init 能不能当“修复”用？
git init 不是修复命令，它是新建命令 —— 它创建一个空的 .git，不恢复历史、不关联远程、不保留分支。你原本是从 https://xxx.git 克隆的，现在 git init 后得立刻补：git remote add origin https://xxx.git。还要注意默认分支名差异：Git 2.28+ 初始化后是 main，老版本是 master；如果远程是 main，而本地还在 master，git pull 会失败。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
跨环境路径失效怎么查？
Docker 容器里报这个错，大概率是挂载路径没包含项目根目录，比如只挂了 -v $(pwd)/src:/app/src，漏掉了 .git 所在层。WSL 或符号链接下更麻烦：git 不跟随软链接向上搜索，它按真实路径走 —— 你用 ln -s /home/user/project ~/proj 进去后，必须 cd /home/user/project 再操作，否则找不到 .git。容器内慎用 find / -name .git，容易卡死或权限不足；限定范围更安全：find ~ -maxdepth 4 -name .git 2>/dev/null。
真正难排查的不是 .git 缺失，而是它存在但关键元数据（如 HEAD、config、objects/）损坏 —— 表现一模一样，但 git init 解决不了。这时候得靠 git clone --no-checkout origin . 重建，或者从备份恢复。
