Marking specific commits to pull into fork

Question

I have a main site which I have forked off into two new sites. The sites are 80% the same, but there are some differences. So, when making changes on the main site there are certain commits that need to be sent down to the forks and others that do not.

Right now I am handling this by updating my forks with the upstream changes using cherry-pick. So, when I make a change on the main site that needs to be propagated, I then have to log into the two forks and update those individually using cherry-pick. This is kind of tedious however because every time I push a change I then need to immediately log into my two forks and update so I don't forget which commits need to be pulled in vs. which commits don't.

My question is: Is there a way to mark my commits that need to be propagated on the main repo so that in my forks I can just say "Only merge in the commits that are marked" rather than cherry-picking each commit one by one?

Thanks for any tips on how to manage these sites.

---

UPDATE --- I'm too new to answer my own question and this response is too long for the comments - so, I'm tossing it here:

Ah... OK, I think I get it. This is my first foray into forking, so I think I can get a little lost in the terms. It seems like branch and fork can sometimes be interchanged. Let me see if I'm understanding the concept correctly.

I have an original repo that was the original site. When the sites diverged, I should have taken the original repo and forked off into "fork A". This leaves me with the original repo, which I'll now call "upstream". So, I have the master "upstream" which was forked off into fork A.

So, I go along working in fork A and I have commits that I want to pull back into "upstream". To pull these over, I'd checkout upstream with "git checkout upstream/master". I could then cherry-pick the shared commits over into that branch and push them.

Now, at a later date after fork A has split off I also spin off Fork B from "upstream". To update Fork B, I would now just do a "git pull upstream/master", right?

Thanks for the help understanding. I'm loving how powerful git is, but it definitely a lot to wrap your brain around. :)

Answer 1

Yes, it's called a branch. In this case, you need a third fork.

If you make master contain only things that are part of the common tree and each branch has it's own special pieces, then you just have to merge the master changes into each forked piece. From your description, it sounds like the current master really doesn't "deserve" that status, and should be a branch, like the others, off a core piece of code that is completely shared.

To do this, I would suggest finding where you forked the other two branches, and creating another one from there. Next, pull the changes you care about from the old master branch into it, and then either declare it new master and merge new changes into it, or you can rebase the existing branches to remove the cherry-picks, so that a simple merge will work well.

PS: if you chose the "clean" rebase route, make backup branches first.