Git: Changing to a Remote Branch From a Clone

I've got a git workflow question, and I don't fully understand all the terms to know what to google for.

The short version: Is it possible to "switch" your local git directory to a branch from a remote repository, when your local repositories started as clones of the remote repository? I'm newish to git, so I'm still coming up to speed on the terminology here; if I've said something that seems off/wrong/making-an-assumption please let me know.

The long version.

I have a local repository that's a clone of "the central" repository. This repository has several branches, each of which is many revisions ahead of the original repository's master branch.

$ git branch
  foo
* master
  universal_imports    

I know I can "switch" to one of my local branches by using git's checkout command

$ git checkout foo
$ git checkout universal_imports
etc.

I also have a few remotes

$ git remote
origin
upstream

The upsteam's master branch is our source of truth. It is the product, the aforementioned central repository. As previously stated, my local master repository started as a clone of this repository. (actually, my local repository is a clone of the origin remote, which is a github fork of the upstream's master branch. I'm unsure if that's relevant)

Here's the scenario I'm trying to solve. I've been doing new development on my branches. I'm many versions ahead of the original master. However, I've just receiv开发者_Python百科ed a request to fix something in production. My mental model here would be to

1. Switch my local code so it matches the production code
2. Do the fix and commit it
3. Merge my local code into the source-of-truth branch
4. Switch my local code back to my "real" branches, and continue new feature development

The goal is to avoid putting any of my new code into production before it's ready.

Short of re-cloning the central repository somewhere, is there a git workflow for this? Ideally I'd like something like i described "switch to a remote branch", but if that's nonsense talk is there a way I could have worked with git that would have allowed me to handle this situation. (blaze ahead on new work, but main the ability to work off a point further back in the history)

You can create a new branch to track a remote branch like this (here the local branch is called 'bugfix'):

git checkout -b bugfix upstream/master

Once you have a local branch tracking and synced with the desired remote branch, you can just make your changes, then git commit and git push, then checkout your original working branch.

Finally, after checking out your working branch again, you'll want to either merge your bugfix change into your working branch like this:

git merge bugfix

Or rebase it like this (rebasing creates a more clean history but can take more work in resolving conflifcts):

git rebase -i bugfix

You can go ahead and leave that branch there (in which case you'll probably want to call it something more permanent than 'bugfix', maybe something like 'upstream-master', or 'live-product', or whatever). Or you can delete the local branch if you don't want it anymore, like this:

git branch -D bugfix