git clone后无法git checkout -b新分支，根本原因是当前用户对.git/refs/heads/等目录无写权限，常见于sudo clone或root拷贝导致属主为root；应先用ls -ld检查权限，再sudo chown -r $user:$user .git修复。
Git clone 后无法 git checkout -b 新分支？先查仓库根目录权限
根本原因往往不是 Git 命令错了，而是当前用户对 .git 目录或其子目录（尤其是 .git/refs/heads/）没有写权限。常见于用 sudo git clone 或从 root 用户拷贝来的仓库——.git 里所有文件属主变成 root，普通用户自然写不进去。
- 运行
ls -ld .git .git/refs/heads，如果看到 owner 不是当前用户（比如显示root root），这就是病根 - 别急着
git branch或git switch，先修复权限：sudo chown -R $USER:$USER .git - 验证：执行
touch .git/refs/heads/test-branch，不报 permission denied 才算修好
git checkout -b 失败提示 “unable to create ‘.git/refs/heads/xxx’” 怎么办
这个错误明确指向 ref 文件创建失败，90% 是上面的权限问题；剩下 10% 可能是磁盘满、SELinux 限制或挂载为只读。优先按顺序排查：
- 先看磁盘：
df -h .，确认所在分区没满（尤其注意/home或/tmp如果 Git 用了 worktree） - 再查挂载状态：
mount | grep "$(pwd)"，输出含ro就说明目录只读，得重新挂载或换路径 - SELinux 用户（如 CentOS/RHEL）加个快速判断：
getenforce返回Enforcing时，临时设为 permissive：sudo setenforce 0，再试一次命令
为什么 git switch -c 比 git checkout -b 更容易触发权限错误？
git switch -c 在 Git 2.23+ 引入，内部逻辑更严格：它会先尝试写 .git/HEAD 和 .git/refs/heads/xxx，任一失败就中止；而老版 git checkout -b 有时会“悄悄” fallback 到 symbolic-ref 方式，掩盖问题。所以新命令反而更容易暴露权限缺陷。
- 遇到
fatal: Unable to create ‘.git/HEAD.lock’: Permission denied，重点盯.git/HEAD.lock的属主和父目录权限 -
git config --global core.autocrlf false这类配置不会影响权限，别浪费时间调它 - 如果仓库在 NFS 或某些云盘同步目录里，检查服务端是否限制了 lock 文件创建（这类环境常禁用
flock）
CI/CD 流水线里出现同样错误，怎么安全修复？
流水线脚本里不能随便加 sudo chown，否则可能破坏构建隔离性。正确做法是在 clone 阶段就规避：
- 用
git clone --config core.filemode=false --config core.autocrlf=false <url></url>，避免因文件模式继承引发权限继承 - Docker 场景下，在
Dockerfile中指定非 root 用户运行：USER 1001，并确保WORKDIR目录由该 UID 创建 - GitHub Actions 等平台，用
actions/checkout@v4默认已处理权限，但若自定义 workspace 路径，需显式run: chmod -R u+rwX ${{ github.workspace }}
权限问题从来不是 Git 本身的问题，而是文件系统层的归属没对齐。修完记得删掉临时测试文件（比如前面 touch 的 .git/refs/heads/test-branch），不然下次 git fetch 可能报 ref 名冲突。
