I've forked a Github repo and added an upstream remote as described here. I expect to make some backward-compatible bug fixes for which I'd like to submit upstream pull requests, as well as some major non-backward-compatible changes. This question is about how to manage both of those things in one repo, or whether that's even a good idea. I've described what I intend to do below. I'm very new to working with Git branches, so please tell me whether this makes sense.
Backward-compatible changes
I think I should keep origin/master synced with upstream/master and never merge any changes of my own into this branch. I'll create feature branches off origin/master for any changes that I expect to submit upstream. If they're accepted, I'll merge upstream/master into origin/master and delete the branches.
Non-backward-compatible changes
I think I should create a separate branch off origin/master to aggregate all my own changes. This branch would be called origin/my-version or something like that. I would merge my backward-compatible branches into this branch without waiting for them to be accepted upstream. I would work on non-backward-compatible changes in branches of my-version. Whenever I merge upstream changes into origin/master, I'd rebase my-version on the new origin/master HEAD. I don't expect a lot of merge conflicts because the upstream project is mature and development is slow.
My main doubt is whether merging my backward-compatible branches into my-version will create problems if those changes are later accepted upstream and I merge them into origin/master. What effect would this have on rebasing my-version, if indeed rebasing is what I should do?
