Git 2.28+ 可通过 git config --global init.defaultBranch main 设置新仓库默认分支为 main，但该配置仅影响 git init 和无明确 HEAD 的克隆，不影响已有仓库或远程仓库的默认分支；需同步修改 GitHub/GitLab 等平台默认分支设置并更新远程 HEAD 才能确保 clone 使用 main。
Git 2.28+ 如何设置全局默认分支名
Git 从 v2.28 开始支持通过 init.defaultBranch 配置项指定新仓库的默认分支名，替代传统的 master。这个设置只影响后续新建的仓库（git init 或 git clone 时未显式指定分支），不影响已有仓库。
- 运行命令：
git config --global init.defaultBranch main（推荐用main） - 验证是否生效：
git config --global init.defaultBranch，应输出main - 注意：该配置不会自动重命名你本地已存在的
master分支，也不会影响远程仓库的默认分支设置
为什么 git clone 有时仍创建 master 分支？
即使设置了 init.defaultBranch，git clone 创建的本地分支名仍由远程仓库的 HEAD 指向决定，不是由你的全局配置控制。比如远程仓库的 HEAD 仍指向 refs/heads/master，那 clone 出来的本地分支就是 master，哪怕你本地设了 main。
- 真正起作用的场景是：
git init新建空仓库，或克隆一个「没有明确 HEAD 指向」的裸仓库（极少见） - 要让 clone 也用
main，必须先在远程仓库（如 GitHub/GitLab）里把默认分支改为main，并确保其HEAD指向refs/heads/main - GitHub 上改完后，新 clone 才会默认检出
main；旧仓库需手动git checkout -b main origin/main && git branch -d master
兼容性与协作注意事项
如果你团队还在用 Git < 2.28，init.defaultBranch 会被忽略，git init 仍生成 master。更麻烦的是 CI/CD 脚本、部署工具、第三方服务（如某些 Jenkins 插件）可能硬编码了 master 分支名。
- 建议在项目根目录加
.gitattributes或 README 明确声明：“本仓库默认分支为main” - CI 配置中避免写死分支名，改用
$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')动态获取 -
git checkout不带参数时的行为取决于本地仓库当前状态，和init.defaultBranch无关——它只管“初始化时起什么名”，不管“切哪个分支”
别漏掉远程托管平台的对应设置
本地设了 init.defaultBranch 只解决一半问题。GitHub、GitLab、Gitee 等平台各自维护一套「默认分支」设置，且不读取你的 Git 配置。
- GitHub：Settings → Branches → Default branch → 改为
main - GitLab：Settings → Repository → Default branch → 改为
main - 改完后，还需手动将原
master分支推送到main，并更新远程HEAD（GitHub 会自动做，GitLab 需git remote set-head origin main） - 否则别人 clone 你的仓库，依然拿到
master—— 这点最容易被忽略
init.defaultBranch 只是起点，真正落地得同步动远程配置和周边工具链。 
