新项目直接用 main，老项目如果团队已经习惯 master 可以继续用，关键是全团队统一，不要混用。从技术底层看，两者完全等价，差异主要体现在生态兼容性和团队规范上。
先说结论：master 和 main 在 Git 技术层面完全等价，选择哪个主要看团队习惯和项目历史，新仓库建议跟随 GitHub 默认用 main。
- 适合：新项目直接选 main，老项目评估迁移成本后再决定
- 重点看：团队 CI/CD 配置、文档、脚本中是否硬编码了分支名
- 别忽略：远程仓库默认分支设置需要同步更新，否则推送会出问题
核心差异与选型建议
master 是 Git 早期的默认分支名，来源于主从（master/slave）模型的技术术语。2020 年 GitHub 宣布将新仓库的默认分支改为 main，主要是考虑到术语的包容性。这个变化不是技术升级，而是社区规范的演进。
选型对比：
- main：现代平台默认值，包容性强，新工具链支持更好，适合新项目。
- master：legacy 默认值，旧脚本、旧 CI 配置兼容性好，适合稳定运行的老项目。
真正影响团队协作的不是名字本身，而是团队是否统一使用同一个主分支名。如果仓库里同时存在 master 和 main，开发者会困惑该基于哪个分支开发，CI/CD 流水线可能指向错误的分支，代码审查流程也会混乱。
迁移操作流程（管理员）
如果决定从 master 迁移到 main，以下是标准操作流程。注意：删除远程分支前务必确认团队成员已完成同步。
1. 重命名本地分支
git checkout master git branch -m master main
这步只在本地生效，不会影响远程仓库。
2. 推送新分支到远程
git push -u origin main
-u 参数会设置上游追踪，后续直接用 git push 即可。
3. 更新仓库默认分支设置
在 GitHub 或 GitLab 的仓库设置页面，把默认分支从 master 改为 main。这一步很重要，否则新建的拉取请求还是会指向旧分支。
4. 删除远程旧分支（高风险）
警告：执行此步前，必须确保所有团队成员已完成本地同步，否则他人推送会失败。
git push origin `--delete` master
团队成员同步指南
其他成员在管理员完成推送后，需执行以下命令同步本地环境：
git fetch origin git branch -m master main git branch -u origin/main main git remote set-head origin -a
如果本地有未提交的修改，请先 stash 或提交后再操作。
CI/CD 配置修改示例
检查 .github/workflows、.gitlab-ci.yml 等文件，把里面硬编码的 master 引用改成 main。
GitHub Actions 示例：
# 修改前 on:push:branches: [ master ]# 修改后 on:push:branches: [ main ]
GitLab CI 示例：
# 修改前 only:- master# 修改后 only:- main
常见位置包括分支过滤条件、部署触发规则、保护分支规则等。
怎么验证是否生效
执行以下检查确认迁移完成：
git symbolic-ref refs/remotes/origin/HEAD
应该返回 refs/remotes/origin/main。在 GitHub 仓库首页看默认分支显示是否为 main。尝试创建一个新的拉取请求，确认源分支和目标分支选项是否正确。
运行一次 CI/CD 流水线，确认触发条件和部署目标都指向新分支。如果有自动化脚本，跑一遍看有没有因为分支名变化而报错。
常见坑与排查
- 推送失败：团队成员本地仓库没有同步更新，还在用 master 分支开发。解决办法是通知所有人执行上述同步命令。
- 流水线不触发：CI/CD 配置里硬编码了 master。需要逐个检查配置文件，有些工具的保护分支规则也需要单独更新。
- 文档混乱：文档和教程里的示例代码还写着 master。建议统一更新项目 README 和内部文档，或者在文档开头说明分支命名约定。
- 第三方集成失效：有些第三方集成（如自动部署服务、监控工具）可能缓存了旧分支名，需要在这些平台的管理界面里重新配置。
原文链接：https://www.zjcp.cc/ask/11314.html