At work, we had been doing MIMEDefang development on master in git, and bugfixes on a branch named 2.63-branch. Over time, master diverged significantly from the current maintenance branch. Recently, we decided to rebase our development work on the maintenance branch, but there were just too many ugly conflicts to resolve. As we didn't want to keep all of the code on that branch anyway, the easiest solution was to rename our 2.63-branch to master and resume development there, cherry-picking some of the useful things from the development branch.
Here's how I did the renaming.
First, in your working tree, locally rename master to something else.
git branch -m master old-dev
Renaming a branch does work while you are on the branch, so there's no need to checkout something else.
Then, locally rename the maintenance branch (2.63-branch) to master:
git branch -m 2.63-branch master
Now, time to mess with the remote. Just in case you screw up, you might want to make sure you have a current backup. First, delete the remote's master:
git push origin :master
And now, give the remote your new master:
git push origin master:refs/heads/master
Update: When creating a new branch, the refs/heads/ prefix is needed on the remote side. If the branch already exists (as master did above) only the branch name is required on the remote side.
... and your now-renamed old master:
git push origin old-dev:refs/heads/old-dev
Finally, delete the old name of your maintenance branch to prevent confusion:
git push origin :2.63-branch
Clients will now get the 'new' master branch when they pull.
Note: Thanks to Bart for info on how to properly do the 'push origin' bits, and for generally increasing my git knowledge.