CODEWITHSUNDEEP
git
Erel Segal-Halevi
Erel Segal-Halevi

Reputation: 36715

Merging a development branch into my fork while keeping the option to merge to the main fork

I forked a GitHub project, made some changes in a development branch, and submitted a pull-request. The project owner said he will merge my changes in a week or two, but since then, two months have passed. Meanwhile, I want to make my changes available to the world since I use them in a research paper.

I want to merge my development branch into the main branch in my fork, so that people can use the changes via my fork; but, I also want to keep it possible for the project owner to, eventually, merge my changes into the main fork.

Is this possible?

Upvotes: 3

Views: 1266

Answers (1)

quetzalcoatl
quetzalcoatl

Reputation: 33506

Of course it is - just go to your master, merge with your devel, and there won't be any problems.

The fact that you have sent a pull request does not change anything from the point of view of your repository, or your branches. You can still do whatever you like on your side.

First of all, your repository and his repository are separate. Whatever you do in yours will not reflect his, and vice-versa. This alone means that regardless of you (him) merging the changes into master (or making new ones on devel) *) will not affect the other guy's repo. Also, that pull-request that you sent will stay there, unchanged, *) until he does something with it.

If he merges that pull request, your repository will not notice that. It will stay behind until you synchronize (->PULL) it with his 'parent' repo.

Similarly, his repo will not notice you doing the merge. In fact, after you do it, he could synchronize with your version, just like you can sync with him when he publishes new commits. In Git there's no 'parent' and 'child' repositories, all are equal, so for Git and push/pull/etc operations there's no problem in sync'ing in any direction..

Moreover, if you do the merge now, and he ignores it, and then he does some changes, then after some longer time he decides to merge your patch - you will sill be able to sync with his repo to get the newest changes (and vice-versa). This is because Git remember what was merged with what, and will notice that you already had that your current changes merged in earlier ago.

What would be the point of 'distributed source control system' if you had to wait for him to do anything on his side?

Sure, if the points of time when both of you do their merge diverge greatly, you (he) can get some conflicts when you sync with the other side, but, well, any merge can end up with some.

*) One caveat: Pull-Request do track your repository. If you sent a PR from your devel, you should not leave your devel unchanged until needed. This is because (-> How to update a pull request) if you commit anything new to the devel branch, the GitHub's PullRequest on his side will assume that this is an update and the PR will also update itself with this new commit. So, by sending a PR from devel, you essentially locked up your devel until PR is resolved. This is why you should have made some other branch, i.e. important-fixes-may-2017 (yeah, that's a very bad name), equal to your devel, and make a PR from that branch. That way this branch would be observed by the PR and your devel would be free to play with.

However, this all does not change the fact that your master is free to play with. You can checkout master, merge with devel, and that will NOT change anything from his point of view. That Pull-Request you've sent will get an update only when you commit anything to the branch you originated the PR from - that is - if you commit to devel.

(and for the time being, if you want to change anything more without updating the PR, just create a branch devel2 at the same point as devel and work on that one)

Upvotes: 1

Related Questions