Git执行set-upstream-to设上游分支报错分支不存在 但可查到对应远程分支

问题场景 #

你使用Git 2.31.1（Git Bash环境）向公司GitLab的已有远程仓库推送多个本地分支，远程仓库的对应分支仅包含初始README.md文件，本地代码此前从未纳入Git版本管理。按如下流程操作时，第一个分支能正常完成推送，但后续分支执行设置上游的命令时反复报错：

cd branchx
git init -b branchx
git remote add origin git@my.company.com:project-group/repo.git

# 报错触发点
git branch --set-upstream-to=origin/branchx

git pull --allow-unrelated-histories
git add .
git commit -m "Initial commit"
git push -u origin branchx

报错信息为：

fatal: branch 'branchx' does not exist

但输入命令时在origin/后按两次Tab补全，却能在候选列表中看到目标origin/branchx分支。

核心原因 #

• 触发报错的本质是：新初始化的空仓库没有任何提交时，git init -b <分支名>创建的分支只是一个占位的HEAD指向，并未生成真实的本地分支引用。Git的分支类操作（包括设置上游）会校验本地分支是否真实存在，空仓库状态下这个占位分支不会被识别为有效分支，因此直接抛出分支不存在的错误。
• 第一个分支操作能正常跑通，是因为你在对应目录操作时，本地仓库已经存在真实的分支引用（比如此前有过初始提交），没有处于“空仓库无提交”的占位状态，设置上游的校验逻辑自然能顺利通过。
• Tab补全能看到origin/branchx的现象，是因为Git Bash的补全逻辑并不会严格校验本地缓存的远程分支引用是否有效，遇到origin/开头的参数时，会临时连通远程仓库拉取分支列表作为补全候选。这个拉取过程只是为了生成补全建议，不会把远程分支信息同步到本地的引用库，因此会出现“补全列表有目标分支，但本地实际没有对应引用”的错位情况。

修正后的操作流程 #

调整空仓库状态下的操作顺序，跳过提前手动设置上游的步骤，完全可以规避报错：

cd branchx
# 初始化对应分支的空仓库
git init -b branchx
# 关联远程仓库
git remote add origin git@my.company.com:project-group/repo.git
# 拉取远程分支的引用，合并已有README.md内容
git fetch origin
git pull origin branchx --allow-unrelated-histories
# 提交本地代码
git add .
git commit -m "Initial commit"
# 推送代码，自动关联上游分支
git push -u origin branchx

注：这种操作顺序下，等你执行push -u时，本地仓库已经因为拉取远程README.md产生了第一个真实提交，分支引用是完全有效的，不需要手动提前执行--set-upstream-to命令。

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