Git批量推送分支至新远程失败，单分支推送正常求助

从Bitbucket迁移到GitHub时出现单分支推送正常、批量推送失败的情况，核心原因大概率和GitHub的规则限制或Git批量推送的特殊行为有关，具体可能是以下几种情况：

• 分支保护规则拦截：如果你的GitHub新仓库针对feature/*、fix/*这类分支前缀设置了保护策略（比如要求必须通过PR合并、强制提交签名、仅允许特定角色推送），批量推送时会触发这些规则导致拒绝。而单分支推送时，因为是首次创建分支，部分保护规则可能未生效，或者你的权限刚好允许直接创建新分支但不允许批量变更。
• --mirror的过度推送触发限制：git push --mirror会推送本地所有引用，包括Bitbucket的远程跟踪分支（refs/remotes/oldbitbucket/*）这类GitHub不接受的引用。虽然日志里显示被拒绝的是常规分支，但这类无效引用的推送请求可能导致服务器返回批量失败，牵连其他正常分支。
• 批量推送触发并发或校验限制：--all会一次性推送所有本地分支，当分支数量较多时，GitHub服务器可能无法同时处理大量分支的创建请求，或者一次性校验所有分支的提交历史时触发了大小、合规性检查，返回模糊的“failed”错误。单分支推送时，服务器逐个处理就能通过。
• 仓库权限的批量操作限制：如果你的GitHub账号仅拥有普通写入权限，批量创建分支的操作可能被识别为高风险变更，被仓库的权限策略拦截，而单分支推送属于常规操作不受限制。

排查与解决建议 #

1. 先确认单个未推送分支确实能正常创建：执行git push newremote feature/closebutton，如果成功，说明分支本身无问题，问题出在批量操作上。
2. 检查GitHub仓库的分支保护设置：临时关闭针对目标分支前缀的保护规则，再尝试批量推送，验证是否是规则导致的拦截。
3. 获取详细错误日志：用git push --all --verbose newremote执行，GitHub通常会返回更具体的拒绝原因（比如“requires signed commits”），之前的精简日志可能隐藏了关键信息。
4. 替换批量推送方式：放弃--mirror，改用指定分支前缀的推送命令，比如git push newremote main dev feature/* fix/* release/*，减少一次性推送的分支数量。

内容的提问来源于stack exchange，提问作者GenError