默认分支改名叫什么
把默认分支从 master 改为 main 这类约定，涉及平台侧与本地侧两条线：平台侧改默认分支并核对保护规则与流水线触发；本地与脚本侧更新引用、重设跟踪关系。影响面广但步骤机械，核心是「先列清单、再执行、分批通知」；实施时先平台后脚本、最后清理旧分支，任何一步都别抢跑。
基本信息
| 平台侧 | 修改默认分支、保护规则与流水线触发条件 |
|---|---|
| 本地侧 | 改名并重设上游跟踪关系 |
| 检索清单 | 脚本、徽章、模板、文档中的旧分支名 |
| 时机 | 选平静期执行，避开发布窗口 |
| 回退 | 改名前记录保护规则配置，便于快速还原 |
典型使用场景
- 行业惯例迁移：master 改名 main，与主流托管平台默认一致。
- 组织规范统一：多仓库默认分支命名对齐。
- 仓库合并后：整理来源仓库遗留的分支名。
- 交接审计：分支命名与内部文档规范保持一致。
- 多平台镜像：GitHub 与内部 GitLab 双向镜像的默认分支同步改名。
本地同步示例
本地同步示例
git branch -m master main # 本地改名
git fetch origin # 拉取远端最新状态
git branch -u origin/main main # 重设上游跟踪
git remote set-head origin -a # 刷新远端 HEAD 指向缓存
git push -u origin main # 远端未改名时先推新分支
git push origin --delete master # 平台侧切换默认后再清理旧分支影响面清单
| 对象 | 要做什么 | 易漏点 |
|---|---|---|
| 保护规则 | 迁移到新分支名 | 规则可能仍挂在旧名 |
| 流水线触发 | 更新分支过滤条件 | 只对 main 触发的任务会停跑 |
| 徽章与文档 | 全局检索替换旧名 | README 链接与状态徽章 |
| 本地克隆 | 重设跟踪或重新克隆 | 旧 master 不自动跟随 |
| 镜像与脚本 | 更新同步目标 | 定时任务静默失败 |
改名影响面广（保护规则、触发器、文档、镜像），先列清单再执行、分批通知；通知里附上本地同步命令，能省去大量重复询问。改名后旧名通常还能继续访问一段时间，但不要依赖重定向长期兜底。