Git clone远程仓库时默认分支为master但HEAD指向main异常咨询

该问题的核心是远程服务端对外通告的HEAD符号引用，和你在服务器磁盘上看到的裸仓库HEAD文件内容不一致。
本地克隆裸仓库时走本地文件传输协议，Git直接读取磁盘上的HEAD文件内容，所以表现正常；但通过SSH/HTTP/Git原生协议从远程服务器克隆时，客户端不会直接读服务器磁盘文件，而是接收服务端进程返回的引用列表，一旦服务端没有同步HEAD的改动，就会返回旧的默认分支指向。
常见触发场景：

• 手动修改了服务器裸仓库的HEAD文件指向main，但没有通过Git官方命令更新引用，部分服务端实现（老版本Git守护进程、Gitosis、配置异常的自建Git托管服务）不会自动感知磁盘文件的改动，对外仍然通告默认分支为master。
• 克隆使用的账号没有main分支的读取权限，服务端会自动回退到第一个有权限访问的有效分支作为默认分支，通常就是遗留的master分支。
• 本地Git版本低于2.28，存在默认分支识别的兼容逻辑缺陷，无法正确解析远程返回的HEAD指向。

服务端侧根本修复 #

1. 登录Git服务器进入对应裸仓库目录，不要手动编辑HEAD文件，执行官方命令更新符号引用：

# 设置HEAD指向main分支
git symbolic-ref HEAD refs/heads/main
# 验证设置结果，正常应输出 refs/heads/main
git symbolic-ref HEAD

2. 如果使用GitLab/Gitea/Gogs等可视化托管服务，不要直接修改磁盘文件，进入仓库设置页找到「默认分支」配置项，在界面中将默认分支切换为main并保存，服务端会自动同步所有引用配置，不会出现不一致问题。
3. 检查仓库分支权限配置，确认克隆使用的账号拥有main分支的拉取权限，不要给默认分支设置不必要的访问限制。

本地侧临时处理 #

如果暂时没有服务端操作权限，可以在本地执行操作修正：

1. 克隆完成后手动同步远程HEAD指向并切换分支：

# 切换到main分支
git checkout main
# 强制拉取远程最新的HEAD引用，更新本地远程分支记录
git remote set-head origin -a

2. 若本地Git版本过旧，可直接升级到2.28及以上版本，也可以在克隆时手动指定分支绕过默认分支识别逻辑：

git clone -b main <你的仓库地址>

内容的提问来源于stack exchange，提问作者Martin Daniel