根据我自己的测试和OP的评论，我认为在某些时候他们在分支名称的外壳上做了一些傻事。

首先，我认为OP是在OS X或Windows等不区分大小写的操作系统上。然后他们做了这样的事情……

$ git checkout -b SQLMigration/ReportFixes
Switched to a new branch 'SQLMigration/ReportFixes'

$ git push origin SqlMigration/ReportFixes
fatal: SqlMigration/ReportFixes cannot be resolved to branch.

注意套管的不同。还要注意，这个错误与您只是键入名称时的错误非常不同。

$ git push origin SQLMigration/ReportFixme
error: src refspec SQLMigration/ReportFixme does not match any.
error: failed to push some refs to 'git@github.com:schwern/testing123.git'

因为Github使用文件系统来存储分支名称，所以它会尝试打开.git/refs/heads/SqlMigration/ReportFixes。因为文件系统是不区分大小写的，它成功地打开了.git/refs/heads/SqlMigration/ReportFixes，但是当它尝试区分大小写比较分支名称时，它们不匹配时就会感到困惑。

How they got into a state where the local branch is SQLMigration/ReportFixes and the remote branch is SqlMigration/ReportFixes I'm not sure. I don't believe Github messed with the remote branch name. Simplest explanation is someone else with push access changed the remote branch name. Otherwise, at some point they did something which managed to create the remote with the typo. If they check their shell history, perhaps with history | grep -i sqlmigration/reportfixes they might be able to find a command where they mistyped the casing.

也许你忘了运行git取回?需要从远程repo获取数据!尝试运行git fetch remote/branch

Git将允许您使用不同的套管签出当前分支，并且它将无法在远程上找到引用。

这是我吃过苦头才知道的。

对于我的例子，我曾经有一个大写字母的分支文件夹(或者不管它叫什么)，然后我用差分大小写(小写)创建了一个新文件夹，但git实际上用大写创建了分支。

I have created a branch like feature-ABC/branch1 before and pushed it. Then I create a branch feature-abc/branch2 (notice the lower-case ABC), and try to push it to remote using git push --set-upstream origin feature-abc/branch2 and get the 'cannot be resolved to branch' error. So I git branch and see that it actually created feature-ABC/branch2 instead of feature-abc/branch1 for me. I checkout again with git checkout feature-ABC/feature2 and push it using the uppercase (feature-ABC/feature2) to solve it.

类似的事情也发生在我身上。我创建了一个名为“Feat/name”的分支。 我试着用:

git push——set-upstream origin Feat/name

我和你犯了同样致命的错误

致命:专长/名字不能解析到分支

为了解决这个问题，我创建了一个新的分支，因为我只有很少的文件受到影响。然后我列出了我的分支来删除错误的分支，它显示没有上限:

壮举/名称

我以前用过大写，但从来没有在第一个字符上用过。看起来git不喜欢它…

我也有这个问题，快把我逼疯了。我有一些类似于feature/name的东西，但是git branch -a显示了我feature/name。重命名分支、删除分支和重新创建分支，这些都不起作用。最终解决问题的是:

进入。git/refs/heads

您将看到一个FEATURE文件夹。将其重命名为feature。

你可能创建了类似的分支，但区分大小写不同，那么你必须运行:

git分支-D <name-of-different case-branch>

然后再试着推。

我遇到了同样的问题，这是由于去分支错误的套管。git让我切换到分支与不正确的套管即功能/名称而不是功能/名称。找到了一个比上面列出的更简单的解决方案:

提交你的更改到'feature/Name' Git主签(或开发) Git签出特性/名称<使用正确的大小写 git推

如果你在本地分支，可以重命名分支“Feature/Name”为“Feature/Name”

git -m功能

如果你在推git时遇到问题，在其他分支(ex develop)进行签出，然后返回到重命名的分支

git签出特性/名称

再试试你的git push

@Ty Le的回答略有修改:

我不需要修改文件——我有一个名为“Feature/…”的分支。，在往上游推的时候，我把标题改成了“feature/…”(第一个字母的大小写被改成了小写字母)。

我也有这个问题，我的正常分支开始于pb-3.1-12345/namebranch，但我意外地大写了前2个字母PB-3.1/12345/namebranch。在重命名分支以使用小写字母之后，我可以创建分支。

我把布兰奇命名为

Rel4.6 /错误/ Some-short-description

我所要做的就是在使用的时候

git push origin Relx.x/bug/Some-short-description

写

git push origin relx.x/bug/Some-short-description

就像我过去在rel中使用小写字母r创建分支一样。

那么，是什么导致了这个问题?

当我列出。git/refs/heads内容时，我找到了

drwxr-xr-x  4 eslam_khoga  staff   128B Sep 22 20:22 relx.x

但是不要放松!

里面还有我分行的名字。

因此，git尝试创建一个名称相同但大小写不同的目录

但是系统不区分大小写。

这就是导致这个问题的原因!

它是大小写敏感的，只要确保创建的分支和推送到分支都是相同的大写。

例子:

git checkout -b "TASK-135-hello-world"

错误的做法:

git push origin task-135-hello-world     #FATAL: task-135-hello-world cannot be resolved to branch

正确的做法:

git push origin TASK-135-hello-world

我在Windows 10中通过使用cmd而不是GitBash解决了这个问题。

这与字符大小写以及git和命令行如何处理它们有关。

不同的套管也有同样的问题。

对开发(或master)进行签出，然后将名称(错误的名称)更改为其他名称，如test。

git checkout development
git branch -m wrong-name test

然后将名称改回正确的名称

git branch -m test right-name

然后签出到右名称分支

git checkout right-name

然后推送到远程分支

git push origin right-name

对我来说，问题在于我将git和macOS文件系统设置为两种不同的大小写敏感性。我的Mac被格式化为APFS/Is Case-Sensitive: NO，但我在某些时候翻转了我的git设置，试图克服Xcode图像资产命名的奇怪问题，所以git配置-global core。ignorecase假。把它翻转回来，调整设置，重新创建分支，然后按一下，让我回到正轨。

git config --global core.ignorecase true

Credit: Git是大小写敏感的，你的文件系统可能不会-奇怪的文件夹合并在Windows上

我遇到了同样的问题，并注意到我在检查分支时混淆了套管。我检查了branchName而不是branchName，当我试图推到远程时，我得到了同样的错误。

解决办法:

git push --set-upstream origin BranchName

通过将上游设置为正确的名称，正确的分支在github上更新，然后我能够签出正确的分支名称

git checkout BranchName 

它应该是最新的，你的最后一推。

似乎你试图重命名你的主分支为主。 使用这个命令git branch -M你在主分支上的Main。 执行这个git命令，il将工作:

git push --all -u

在此之后，您可以运行git分支来查看您的分支 然后你可以像这样删除主分支:

git branch -D master

我的2美分…在我的案例中出现这个问题是因为分支名称中的一个拼写错误(大写字母)。我有两个名字几乎一模一样的分支。

对我来说，git状态给了我错误的分支名称，hotFix/issue-233而不是hotFix/issue-233。Git分支没有显示正确的分支名称。

知道分支字母是区分大小写的，这就是我面对的，我试着按“header”而不是“header”

在我的例子中，原因是正确的分支名称是大写的，但在push命令中指定的分支名称是小写的。

$ git branch --contains=HEAD

上面的命令将告诉您正确的分支名称，因此按下它。

在遇到类似的问题后，我决定张贴对我有用的东西。

我尝试用命令将新的分支推到远程存储库:

git push --set-upstream origin <branch name copied from Git console after navigating to the repository location>

并得到以下状态信息:

warning: redirecting to <myRepositoryAdress>

fatal: <branch> cannot be resolved to branch

首先，我们迁移了Git，我认为这可能是问题所在，但事实并非如此。

实际的问题是:

而不是将分支命名为:bugFix/UserName/BranchName，它在Git控制台上被写成bugFix/UserName/BranchName(注意这里小写的f)。 我通过输入git branch -a并将所有现有的分支与我签出/想要推送的分支进行比较来计算出这一点。控制台是如何出现小写f的，我仍然不知道。当然，如果实际本地分支的名称与您在推送时输入的名称不同，则该名称不能解析为分支!

在我的SmartGit GUI中，提交是在正确的分支上，但我更喜欢控制台和从那里推送，所以SmartGit更像是一个检查本地状态日志的步骤，并比较控制台中是否有一些错误。

我从中学到的是:

如果你的目标只是推送一个本地分支，就不要像一些人在有关这个错误的文章中建议的那样使用git push——all -u。

最好试着弄清楚到底哪里出了问题以及原因。然后寻找解决方案。也许你也有一个拼写错误或一些类似的不一致。

如果你使用的是Omegaman/BugFix这样的文件夹，请确保案例是正确的。似乎你可以签出一个现有的分支作为小写omegaman/BugFix并尝试推送，它会失败。

用正确的外壳重新检出，如git检出Omegaman/BugFix来解决。

分公司名称请用小写字母，不要用大写字母。它会起作用的。

我从Feature/name签入到Feature/name，它解决了我的问题。

尝试这个错误:(feature/test是本地分支名称)

Git分支——set-upstream-to=origin/feature/test feature/test

我在windows系统中也遇到了同样的问题。使用 Git checkout -b your-new-branch从你当前的分支并推送到远程，然后你可以在两个分支中找到提交。

如果你有另一个看起来相似的分支，试着重新命名你的分支。

我认为GitHub文件系统有点纠结于相同的分支名称，如果它们区分大小写的话。在我的例子中，我在服务器上有一个这样的分支，

Feature/Settings/Billing

过了一段时间，我试图发布另一个类似的分支，

Feature/Settings/Billing-After-Revamp

然后我得到了一个致命的错误，然后我重命名了新的分支，如下所示，

Feature/Settings/After-Revamp-Billing

它就像一个魅力，我能够成功地发布我的分支没有致命的错误，如上述。

我在名为“bugFix/issue-2521”的分支上也有这个问题，我意识到我已经有了相同的分支名称，但没有大写字母“bugFix/issue-2521”，我在创建这个新分支时没有遇到冲突，但我在升级这个分支时遇到了问题。 这个问题最简单的解决方案是将其重命名为git branch -m new-branch-name