GeezerVison

Is this best practice, or should I make a local v1.0.x first and then create the feature branch off of that?

I don't see any real reason to create an intermediate local branch.

Either one should be fine. Personally, I have a local v1.0.x branch that I set up to track matplotlib/v1.0.x, not darrendale/v1.0.x. I don't want to worry about keeping my remote darrendale/v1.0.x branch in sync with matplotlib/v1.0.x.

I think the best practice can be stated thus: if the remote has a branch v1.0.x and you make a local copy of it, the state of your local copy should not diverge from the remote. Use "git pull" occasionally to keep it in sync with the remote, and especially when you are about to do a merge. The only time the state of your local copy should diverge from the remote is right before a push, when you do the merge. Right after the push, your local copy and the remote are once again in sync.

By the way, this:

git branch my-new-feature remotes/origin/v1.0.x
git checkout my-new-feature

is equivalent to:

git checkout -b my-new-feature remotes/origin/v1.0.x

and it also appears to be equal to:

git checkout -b my-new-feature origin/v1.0.x

One final comment: I find the "origin" and "upstream" convention to be confusing. Instead, I name my remotes after the github profiles: "matplotlib" instead of "upstream", "darrendale" instead of origin. Its a little more concrete.

After reading Jouni's comment and rereading my own, I think I agree that it is easier to not have an intermediate, local v1.0.x branch.

I think changing the two commands to "git checkout -b my-new-feature origin/v1.0.x" makes sense.

Typo at end of line: you have a semicolon instead of a colon in the next-to-last character.