6

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

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.