升级后遇到默认分支名变化，通常是因为 Git 安装包更新了全局配置默认值，现有仓库不会自动改名，只需调整本地配置或重命名分支即可兼容。
先说结论：这不是 Git 内核强制修改现有仓库，而是新初始化行为或本地配置变更，可根据团队规范选择回退配置或同步分支名。
- 适合：升级 Git 后发现新建仓库默认分支为 main，或原有脚本依赖 master 分支的场景
- 先准备：确认远程仓库默认分支名称，备份当前本地分支状态
- 验收：本地分支与远程追踪一致，CI/CD 流水线正常触发
命令速用版
如果你希望全局恢复为 master 作为默认分支名，可执行：
git config `--global` init.defaultBranch master如果你希望将当前仓库适配为 main 分支，可执行：
git branch -m master main
git push -u origin main为什么会这样
Git 本身在 2.28 版本引入了 init.defaultBranch 配置项，允许用户自定义初始化分支名。在此之前，硬编码为 master。随着 GitHub 等平台在 2020 年将新仓库默认分支改为 main，后续 Git 安装包（包括 2.39 系列）在安装向导或默认配置中倾向于将 init.defaultBranch 设为 main，以减少与托管平台的差异。
这不会自动重命名你已有的旧仓库分支，但会影响 git init 新建的仓库，或者在某些克隆操作后的本地表现。如果你原有的自动化脚本、CI 配置硬编码了 master，就会出现不兼容。
分步处理
第一步：确认远程默认分支
先查看远程仓库实际使用的默认分支名，避免本地修改后与远程不一致：
git remote show origin在输出中寻找 HEAD branch 字段，确认是 master 还是 main。
第二步：选择兼容策略
方案 A（保留 master）：如果团队规范仍使用 master，修改全局配置，影响后续新建仓库：
git config `--global` init.defaultBranch master方案 B（迁移到 main）：先在远程仓库平台设置 main 为默认分支，再重命名本地分支并更新追踪：
git branch -m master main
git push -u origin main远程仓库默认分支切换（前置步骤）
若选择方案 B 并需要删除旧分支，必须先在代码托管平台将默认分支切换为 main，否则仓库将失去默认分支，导致 PR/MR 无法创建或推送失败。
GitHub 操作：
- 进入仓库 Settings -> Branches
- 在 Default branch 处点击切换图标，选择 main
- 确认更新
GitLab 操作：
- 进入仓库 Settings -> Repository
- 展开 Default branch 选项
- 选择 main 并保存
切换完成后，再执行删除旧分支操作：
git push origin `--delete` master第三步：更新本地脚本
检查项目中的 CI 配置文件（如 .gitlab-ci.yml、GitHub Actions 工作流），将引用的分支名从 master 替换为 main，或反之。
怎么验证是否生效
执行以下命令检查当前分支状态：
git branch -a确认当前所在分支（带星号标记）与预期一致。如果是迁移方案，再执行 git status 确认没有未推送的变更，且追踪路径显示为 origin/main。
对于 CI/CD 验证，尝试触发一次流水线，观察是否因分支名不匹配而失败。
常见坑
1. 受保护分支：在 GitHub 或 GitLab 上，如果 master 被设为受保护分支，直接删除或重命名可能受阻，需先在网页端调整默认分支设置并解除保护。
2. 克隆旧仓库：即使 Git 版本较新，克隆现有仓库时通常会保留远程的默认分支名，不会强制变 main，除非远程已改。
3. 子模块依赖：如果项目包含子模块，且子模块脚本中硬编码了分支名，需同步检查子模块配置。
参考来源
- Git 官方文档 - git-config：https://git-scm.com/docs/git-config
- GitHub Blog - Highlights from Git 2.28：https://github.blog/2020-07-27-highlights-from-git-2-28/