[juliusdavies]

He might like doing this:

  git push origin HEAD:refs/heads/MY_NEW_BRANCH".

If you add a "+" character, it becomes a force-push:

  git push origin +HEAD:refs/heads/MY_NEW_BRANCH

Let's me work from master locally, but push my work to a new remote branch just for the PR. Saves a couple steps in his normal workflow as he describes it. I also tend to use the "Squash", "Rebase" and "Amend" buttons on the PR's web UI that makes a few of my common "post-push" operations even more convenient (thanks to a Bitbucket plugin).

Oh, and "git pull --rebase --autosquash" is also a big part of my workflow. Quite a miraculous "does exactly what you want without you even knowing you want it" command.

[kazinator]

When would you want to autosquash things coming from another repo? Autosquash is for doing interactive rebases; you'd never want to publish commits that say "squash! ..." or "fixup! ...".

[ajross]

Yeah, "all branches are remote" is in fact the Objectively Best Workflow.

In point of fact I don't deal with local branches at all on 95%+ of days. Just "git reset --hard <remote>/<branch_to_work_on>", do whatever I want, and then "git push <remote> HEAD:refs/heads/<pull_request>" (or push -f if I'm reworking an existing one, yada yada). If I want to "pull" changes I just "git fetch <remote>" and don't ever bother checking anything out.

Local branches involve too much state that inevitably means I trip over it.

[juliusdavies]

Heartily agree! I never thought of my workflow in this way, but it makes sense: by completely avoiding local branches, I reduce my cognitive load. I only ever work from "master", but my "master" is just whatever I happen to be working on that day.