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 'git@github.com: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.