I haven’t tried yet, but here is a stackoverflow answer[1] showed that git can magically skip the “same” cherry-picked commit even for the rebase case. Then rebase on there own branches should be fine.
[1] http://stackoverflow.com/questions/14509878/why-does-a-rebase-after-a-cherry-pick-not-apply-the-same-commit-twice <http://stackoverflow.com/questions/14509878/why-does-a-rebase-after-a-cherry-pick-not-apply-the-same-commit-twice> > On Sep 24, 2015, at 12:01 AM, Chris Hillery <[email protected]> wrote: > > On Wed, Sep 23, 2015 at 11:38 PM, Chen Li <[email protected]> wrote: > >> Just want to echo what Ted said: if the same commit exists in two >> different branches, then there is no issue when we merge these two >> branches into the master. In fact, if branch A has all the commits of >> branch B, after we merge branch A into the master, git will >> automatically think branch B is already merged into the master. > > > This is true, and one of the key benefits to the merge scenario. However, I > feel it's important to point out again that a cherry-picked commit is *NOT* > "the same commit" as far as git is concerned, so if you cherry-pick from A > to B then A and B do not have the same commits. It may be that git merge > and/or rebase can detect cherry-picks and handle them better than > completely exploding. But if you think of them as the "same commit", you're > giving yourself a bad understanding of what's actually going on, and that > will eventually bite you. > > (I know you didn't specifically mention cherry-picking, Chen, but in the > context of Jianfeng's and Ted's earlier messages I think it's still a point > that bears repeating.) > > Ceej > aka Chris Hillery Best, Jianfeng Jia PhD Candidate of Computer Science University of California, Irvine
