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.
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
origin/master and delete the branches.
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?