Can't push to remote branch, cannot be resolved to branch

S

34

282

I migrated my repos from Bitbucket or Github. I don't think this matters but it's the only thing different. For a little while, I had two remotes set up:

origin: bitbucket
github: github

Then I removed both and pointed origin to github:

git remote remove origin
git remote remove github
git remote add origin https://github....

Test push of develop branch:

git push origin develop

Everything up to date, ok, good.

Create a new branch for some work as per usual:

git checkout -b Feature/Name

Update a file or two. Attempt to push to remote:

git push origin Feature/Name

This results in the error:

fatal: Feature/Name cannot be resolved to branch

Search online for this issue, find some stuff about ensuring HEAD is correct, others about making sure I've got my branch name case correct (though, at this point the branch doesn't exist on the remote yet). Unable to resolve.

Ran this command:

git push --all -u

This got my Feature/Name branch to github, but still see same behavior as prior:

git push origin develop
git push origin Feature/Name

The first works while the second throws the same error. Why?

Simulacrum answered 26/6, 2016 at 3:9 Comment(7)

What branch were you on when you made Feature/Name? Are you sure Feature/Name exists and that's the checked out branch? Check with git branch. – Diamagnet 26/6, 2016 at 3:23

@Diamagnet - Only three branches existed (locally and on remote): develop, test and master. Once a branch is cleaned up and merged back to develop I delete them locally (and remotely if applicable). I'm certain there were only my three - I haven't opened the project in a while and first thing I did was check and make sure I had no loose branches. – Simulacrum 26/6, 2016 at 3:32

Does that mean you ran git branch to verify Feature/Name exists locally? Don't trust a GUI or IDE. Also, did you get the case right? – Diamagnet 26/6, 2016 at 3:37

How about git push origin Feature/Name:Feature/Name? – Esquire 26/6, 2016 at 3:40

Now I'm pissed... not sure why it didn't work in the first place, but after using git push --all -u I have the new branch in github, but still couldn't push from local, right? Here's what happened with that... the actual branch name is SQLMigration/ReportFixes and what is in github is SqlMigration/ReportFixes. So, now I can git push origin SqlMigration/ReportFixes - whytf does github change casing for me? Agh. – Simulacrum 26/6, 2016 at 3:56

@Diamagnet - yes, git branch is how I check, I rarely use GUIs for git. @Esquire - tried that too, got an error, then was going to grab a screenshot and realized the oh-so-helpful auto-case-change in the github branch per my previous comment. – Simulacrum 26/6, 2016 at 3:57

@jdl134679 then try git push origin Feature/Name --. Is it possible that Feature/Name can be resolved as a file in your repo? – Esquire 26/6, 2016 at 4:50

P

891

I was having this issue as well, and it was driving me crazy. I had something like feature/name but git branch -a showed me FEATURE/name. Renaming the branch, deleting and recreating it, nothing worked. What finally fixed it:

Go into .git/refs/heads

You'll see a FEATURE folder. Rename it to feature.

Precursor answered 15/3, 2017 at 6:11 Comment(4)

The problem is that the remote and local branch have different cases. There are a number of ways to solve this. Either rename the branch or push the branch using the correct case. I just pushed to the remote branch with the correct case, checkout out the branch using the same case. Then the old branch with the incorrect case simply disappeared from branch -a – Rihana 30/10, 2019 at 8:10

For the quick and not quite as nice fix, try git checkout -b new-branch-name and just use another branch name – Gearard 12/2, 2021 at 16:55

Excellent, did work as expected. Was not aware of the capital folder name against lowercase folder name would cause an issue. – Dionysiac 19/1, 2023 at 3:47

This happened to me on Windows. Windows is case-insensitive, so I already had a branch named like "devName/taskName" and I created a new branch named "DevName/otherTaskName". In Windows, the "gitProjectRoot>/.git/refs/heads/devName" folder was already created with lower case and so the one with the first letter capitalized could not be created. However, when pushing it needs to match the case of these folders in the file structure, so I simply changed my push command from this to get it to work: git push origin DevName/otherTaskName To this: git push origin devName/otherTaskName – Gaige 8/3 at 18:5

D

58

Based on my own testing and the OP's comments, I think at some point they goofed on the casing of the branch name.

First, I believe the OP is on a case insensitive operating system like OS X or Windows. Then they did something like this...

$ 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.

Note the casing difference. Also note the error is very different from if you just typo the name.

$ git push origin SQLMigration/ReportFixme
error: src refspec SQLMigration/ReportFixme does not match any.
error: failed to push some refs to '[email protected]:schwern/testing123.git'

Because Github uses the filesystem to store branch names, it tries to open .git/refs/heads/SqlMigration/ReportFixes. Because the filesystem is case insensitive it successfully opens .git/refs/heads/SqlMigration/ReportFixes but gets confused when it tries to compare the branch names case-sensitively and they don't match.

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.

Diamagnet answered 26/6, 2016 at 4:52 Comment(3)

I ran into this problem when I changed the case of characters in the branch name on OS X. Changing them back resolved the issue. – Editorial 8/3, 2017 at 21:25

This can also happen when you have a previous branch, say AM-xxx/some_branch, and then create another one AM-XXX/another_branch, git will allow the differing cases locally and fail to pair the two remotely. – Kerenkeresan 3/1, 2018 at 10:54

Yes it is possible to check out in the wrong mixed case but not check in .. Just messy. – Juback 24/1, 2019 at 0:43

A

31

Git will let you checkout the current branch with a different casing, and it will fail to find a ref on the remote.

Just found out the hard way.

Alcohol answered 26/10, 2016 at 8:6 Comment(3)

this was my issue. I would suggest doing a quick > git branch and verify that your branch has a * next to it. – Sheryllshetland 19/7, 2018 at 13:21

This happened to me as well. @AndyDangerGagne, I'm glad you suggested this -- there was no * next to the branch that I was on, so I checked it out again, this time in lower case. – Windup 2/1, 2019 at 21:31

I'm not exactly sure I understand what happened. I have a new branch that I couldn't push because of the same reason and thought I would try changing the first letter of the branch name to uppercase and it worked. I'm guessing the branch already existed and I didn't realize it, although i didn't see it. – Unsparing 27/9, 2021 at 15:40

D

18

The cause in my case was that the correct branch name was in uppercase, but the branch name specified in the push command was in lowercase.

$ git branch --contains=HEAD

The above command will tell you the correct branch name, so push it.

Damron answered 10/10, 2021 at 14:59 Comment(2)

This solved my problem. Thanks for posting the solution. – Downandout 25/8, 2023 at 13:15

that did it, when nothing else worked. thanks! – Marrero 31/8, 2023 at 18:50

M

14

Please use small alphabet letters for branch name, don't use capital letters. It will work.

Mete answered 28/12, 2021 at 11:16 Comment(1)

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Wortham 28/12, 2021 at 12:33

B

12

It's case-sensitive, just make sure created branch and push to branch both are in same capital.

Example:

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

WRONG way of doing:

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

CORRECT way of doing:

git push origin TASK-135-hello-world

Bryon answered 29/11, 2019 at 8:20 Comment(0)

S

11

A similar thing happened to me. I created a branch called something like "Feat/name". I tried to pushed it using :

git push --set-upstream origin Feat/name

I got the same fatal error as you :

fatal: Feat/name cannot be resolved to branch

To solve it I created a new branch as I had very few files impacted. Then I listed my branches to delete the wrong one and it displayed with no cap :

feat/name

I had used caps before but never on the first caracter. It looks like git doesn't like it...

Subsidize answered 19/1, 2017 at 13:58 Comment(2)

I had the same case THX :D – Arlindaarline 28/9, 2017 at 13:31

for my case, this won't work because I have a branch called develop, so ? – Crawfish 23/10, 2021 at 17:32

K

5

For my case, I used to have branch folder (or whatever it is called) with capital letters, then I create a new one with difference casing (lowercase) but git actually create the branch with capital.

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.

Krispin answered 1/12, 2016 at 17:9 Comment(0)

L

5

Had the same problem with different casing.

Did a checkout to development (or master) then changed the name (the wrong name) to something else like test.

git checkout development
git branch -m wrong-name test

then change the name back to the right name

git branch -m test right-name

then checkout to the right-name branch

git checkout right-name

then it worked to push to the remote branch

git push origin right-name

Lozenge answered 24/4, 2020 at 14:45 Comment(0)

A

3

I faced the same issue which was due to going to branch with wrong casing. git let me switch to branch with incorrect casing ie feature/Name instead of feature/name. Found an easier solution than listed above just:

commit your changes to 'feature/Name'
git checkout master (or develop)
git checkout feature/name < with correct casing
git push

Aires answered 16/7, 2018 at 13:43 Comment(0)

P

3

I solved this in Windows 10 by using cmd instead of GitBash.

It has to do with character case and how git and command lines handles them.

Perspire answered 9/12, 2019 at 15:45 Comment(0)

P

3

I checked out from Feature/name to feature/name and it resolved my issue.

Polytrophic answered 31/1, 2022 at 19:36 Comment(0)

S

3

I ran into the same problem caused by incasesensitive in windows system. Use git checkout -b your-new-branch from you current branch and push to remote, then you can find commits in both.

Shriek answered 30/3, 2022 at 18:5 Comment(0)

D

3

I was having this issue as well with the branch named "bugFix/issue-2521", I realized that I already had the same branch name but without the capital letter "bugfix/issue-2521", I haven't faced conflict with creating this new branch however I facing issue when making upstreaming this branch. the simplest solution for this issue is to rename it git branch -m new-branch-name

Depurate answered 26/10, 2022 at 8:23 Comment(0)

K

2

Maybe your forgot to run git fetch? it's required to fetch data from the remote repo! Try running git fetch remote/branch

Kinny answered 26/6, 2016 at 12:16 Comment(0)

M

2

For me git status was giving me the incorrect branch name, hotFix/issue-233 instead of hotfix/issue-233. git branch did display the correct branch name.

Mimosaceous answered 20/5, 2021 at 15:9 Comment(1)

I wonder why does git status not show the correct branch name? Very weird. – Goebel 16/11, 2021 at 19:35

B

2

Try re-name your branch if you have another branch which look alike.

I think GitHub file system is kind of struggling with same-like branch names if they're case sensitively different. In my case, I had a branch on the server like this,

Feature/Settings/Billing

then I was trying to publish another branch like this after awhile,

Feature/Settings/Billing-After-Revamp

then I got a fatal error like above, then I renamed the new branch as below,

Feature/Settings/After-Revamp-Billing

It worked like a charm and I was able to successfully publish my branch without fatal errors like above.

Betimes answered 1/10, 2022 at 13:40 Comment(0)

E

1

You might have created similar branch but different case-sensitive-wise, then you have to run:

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

and then try to push again.

Eimile answered 28/2, 2018 at 14:59 Comment(0)

L

1

Slightly modified answer of @Ty Le:

no changes in files were required for me - I had a branch named 'Feature/...' and while pushing upstream I changed the title to 'feature/...' (the case of the first letter was changed to the lower one).

Luht answered 1/10, 2018 at 22:30 Comment(0)

E

1

I just had this issue as well and my normal branches start with pb-3.1-12345/namebranch but I accidental capitalized the first 2 letters PB-3.1/12345/namebranch. After renaming the branch to use lower case letters I could create the branch.

Equine answered 4/3, 2019 at 21:52 Comment(0)

K

1

I had the same problem but was resolved. I realized branch name is case sensitive. The main branch in GitHub is 'master', while in my gitbash command it's 'Master'. I renamed Master in local repository to master and it worked! 😀😀

Kala answered 10/7, 2020 at 6:51 Comment(0)

T

1

I ran into the same issue and noticed that I had mixed up the casing while checking out the branch. I checked out branchName instead of BranchName and when I tried to push to remote, I got the same error.

The fix:

git push --set-upstream origin BranchName

By setting upstream to the correct name, the correct branch was updated on github and I was then able to checkout the correct branch name with

git checkout BranchName

And it should be up to date with your last push.

Tanishatanitansy answered 21/7, 2020 at 6:31 Comment(0)

S

1

My 2 cents... This problem occurred in my case because of a typo (uppercase letter) in the branch name. I had 2 branches with almost identical names.

Softfinned answered 28/2, 2021 at 19:7 Comment(0)

M

1

Know that branch letters are case sensitive, that's what I face, I tried pushing to "header" instead of "Header"

Mavilia answered 5/9, 2021 at 11:22 Comment(1)

Please add further details to expand on your answer, such as working code or documentation citations. – Cp 5/9, 2021 at 12:15

P

1

If one is using folders such as Omegaman/BugFix make sure the case is correct. It seems one can checkout an existing branch as lowercase omegaman/BugFix and attempt to push, it will fail.

Recheckout with the proper casing such as git checkout Omegaman/BugFix to resolve.

Peterson answered 21/10, 2021 at 19:39 Comment(0)

F

1

Try this for the error: (feature/test is local branch name)

git branch --set-upstream-to=origin/feature/test feature/test

Flunkey answered 24/3, 2022 at 19:6 Comment(0)

W

1

I just used lower case for the name of the branch and it worked

Wolverhampton answered 4/6, 2023 at 8:23 Comment(0)

S

0

If you are in local branch, could rename the branch "Feature/Name" to "feature/Name"

git -m feature/Name

if you have problems to make a git push make a checkout in other branch (ex develop) and return to renamed branch

git checkout feature/Name

and try again your git push

Spermine answered 7/8, 2018 at 19:5 Comment(0)

R

0

for me I was naming branch as

Rel4.6/bug/Some-short-description

all I had to do is when using

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

to write

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

as I used to create branches using small letter r in rel.

so, what caused this issue?

when I listed .git/refs/heads content I found

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

but no Relx.x!

and inside it bug and inside bug my branch's name.

So, git try to create a dir with same name but different case letters

but system is not case sensitive.

That's what caused this issue!

Rosabelle answered 6/10, 2019 at 18:12 Comment(0)

E

0

For me, the issue was that I had git and my macOS filesystem set to two different case sensitivities. My Mac was formatted APFS/Is Case-Sensitive: NO but I had flipped my git settings at some point trying to get over a weird issue with Xcode image asset naming so git config --global core.ignorecase false. Flipping it back aligned the settings and recreating the branch and pushing got me back on track.

git config --global core.ignorecase true

Credit: Git is case-sensitive and your filesystem may not be - Weird folder merging on Windows

Ecosystem answered 26/5, 2020 at 13:14 Comment(0)

K

0

it seems that you try to rename your master branch to Main. by using this command git branch -M Main where you were on master branch. execute this git command, il will work :

git push --all -u

after this you can run git branch to see your branches then you can delete the master branch like this :

git branch -D master

Klaraklarika answered 21/2, 2021 at 12:16 Comment(0)

F

0

After having the similar problem, I decided to post what worked for me.

I tried to push new branch to the remote repository with the command:

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

and got the following status message:

warning: redirecting to <myRepositoryAdress>

fatal: <branch> cannot be resolved to branch

First of all, we migrated Git and I thought that might be the issue, but not.

The actual problem was:

Instead of having branch named: bugFix/UserName/BranchName, it was written as bugfix/UserName/BranchName in the Git console (notice lowercase f here). I figured that out by typing git branch -a and comparing all existing branches with the one that I am checked out to / want to push. How it happened that the console had lowercase f, I still don’t know. Of course, that the name cannot be resolved to a branch if the name of the actual local branch is different from the name you typed when pushing!

In my SmartGit GUI commit was on the correct branch, but I prefer console and pushing from there, so SmartGit was more like a step to check log of the local state and compare if there is some error in the console.

What I learned from this:

Don’t use git push --all –u as some people suggest in the posts that relate to this error if your goal is to push only one local branch.

Better try to figure out what is exactly wrong and why. Then search for the solution. Maybe you also have a typo or some similar inconsistency.

Fiddler answered 14/10, 2021 at 9:44 Comment(0)

M

0

Met this issue and resolved it with git branch --set-upstream-to=origin/<branch> main

Merry answered 29/4, 2023 at 6:55 Comment(0)

P

0

Windows 10 case : In my case the problem was related to an other folder inside ".git/refs/head/myrepo", I was only able to understand when I combined two answers, one from "ty le" and one from "Schwern", I realized that my git was getting confused, but it was because of the Caps Lock letter on other folder, and because windows is not case sensitive.

So what I did was to Rename it as : ".git/refs/head/Repo" to ".git/refs/head/repo" and then the first one that I wanted to push started to work again.

Parenthesize answered 2/10, 2023 at 13:23 Comment(0)

Recommended topics

Hot tags