在处理这类问题时，我会先确认当前环境是新建仓库还是已有仓库，因为“默认分支使用master还是main”这个问题，在两种场景下的操作路径和风险范围完全不同。如果只是希望以后所有新仓库都以main为初始分支，那修改Git全局配置就够了；但如果仓库已经在协作中，则还要处理分支重命名、远程同步和团队通知。

先确认现状和依赖

动手之前，先花一两分钟检查一下现有代码仓库里有没有对master分支名的硬编码引用。常见位置包括CI/CD配置文件、部署脚本、文档里的checkout命令，以及仓库平台设置中的默认分支选项。如果这些地方明确写了master，那么就算本地改成main，后续流程也可能会找不到分支。

另一个判断点是团队规模。如果仓库只有自己维护，那么迁移成本很低；如果已经有多人协作，或者有自动构建任务依赖默认分支，就需要先商量好统一切换的时间点，再执行下面的命令。

容易误判在哪里

最容易误判的地方，是把“修改Git全局默认分支”当成“修改现有仓库的默认分支”。实际上，git config --global init.defaultBranch只影响之后用git init创建的新仓库，已经存在的仓库不会被自动改掉。这个配置不是开关，不会触发已有分支的重命名。举个例子：你在一个已有仓库里运行git init，分支名不会变成main；必须先在本地把master分支重命名为main，再处理远程关联。

修改新建仓库的默认分支

接着来说新仓库的情况。最直接的修改方法是通过Git全局配置。在终端执行git config --global init.defaultBranch main，这条命令会把新建仓库的默认分支名修改为main。如果只想对当前用户生效，--global是合适的；如果希望所有用户都生效，则需要放在系统配置中，不过通常个人环境用--global就足够。执行后，使用git init创建的新仓库，会直接以main作为初始分支。

如果你使用的是GitHub、GitLab或Gitee这类平台，还需要在平台设置里把默认分支的选项同步改为main。这个设置与本地Git配置相互独立，平台负责管理远程仓库的初始分支和默认展示分支。如果不改，在网页端新建仓库时，生成的README文件等初始内容仍然会挂在master分支上。

验证修改结果

配置完成之后，最好马上验证一下，避免后面新建仓库时才发现分支名还是master。配置完成后，可以执行git config --global --get init.defaultBranch来确认当前值。如果输出main，说明配置已生效。另一种验证方式是创建一个临时目录，执行git init后运行git branch，查看分支名是否为main。注意，git branch命令会列出所有本地分支，初始分支前的星号标识当前所在分支，看到* main就代表成功。

这一节里的两种验证方式可以选一种做。如果使用临时目录验证，记得最后把这个目录删掉，避免留下无用的仓库。

已有仓库的分支迁移

接下来是已有仓库的情况，这也是容易引发事故的部分。修改默认分支不会自动转换已有仓库。如果在已有仓库中希望将master分支改名为main，需要在本地执行git branch -m master main，将当前分支名重命名。如果远程仓库已被其他人使用，还需要使用git push origin main以及设置上游分支，同时删除远程的master分支。删除远程分支时，要确保没有开放的分支审查规则或保护规则，否则删除操作会被拒绝。此外，直接修改远程仓库设置时，需要确认所有协作者都同意，否则会导致混乱。

光执行上面的命令还不够。重命名分支后，远程仓库的默认分支仍然可能指向旧的master，需要在平台设置中手动切换默认分支，再把主要分支保护规则迁移到main上。对于其他协作者的本地副本，也需要让他们先拉取远程改动，再删除或重置本地master跟踪分支，避免后续提交被分流到旧分支。

风险与后续维护

切换到main不是一个孤立动作，而是一个流程变更。它会影响后续所有新仓库的初始化，也要求已协作仓库中的文档、CI脚本、部署工具保持同步。如果项目已经成熟，建议先在本地测试环境开一个仓库，完整演练一遍“重命名、推送、删除远程分支、更新默认分支”的步骤，确认没有问题后再对正式仓库操作。这样即使中途出现问题，也可以及时把分支名改回去，避免影响团队开发。

回滚操作并不复杂：本地把main改回master，远程再删除main并恢复master默认分支，同时把之前的保护和自动化规则重新指向master。但回滚需要所有协作者配合，所以最好在切换前把当前分支状态和相关配置做一个备份。修改默认分支的行为只影响新仓库的初始化，对旧仓库的操作完全取决于你的迁移动作，风险边界要心里有数。