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?