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?
1 Answer 1
Create one branch for you to work in for your non-breaking changes, this should be branched from origin/master.
Create another branch for your breaking changes. This branch should conceptually inherit from your non-breaking changes branch, which inherits from origin/master
Never merge from your breaking branch to your non-breaking branch, and never merge from your non-breaking branch to origin/master
This way, you always do your non-breaking bug-fixes in a version which is able to cleanly pull from the original codebase, and any merge conflicts that happen due to your breaking changes will always happen in your breaking-changes branch, where you can fix them without leaking code to upstream.
As for submitting your pull requests to merge your non-breaking changes upstream, create a repo on your own github account where you push your non-breaking branch (fully merged with origin/master), and submit a pull request from that repo to the upstream repo.
Quick diagram:
origin/master (pull only) -> non-breaking changes (pull only) -> breaking changes (merge conflicts happen here)
Never push up the chain, never merge up the chain.