If I have a public Git repository that contains 3 branches like the following:
(release-to-customerA)
|
U (master)
/
You don't need to rebase for this particular operation, cherry-picking is fine:
git checkout release-to-customerB
git cherry-pick U
git checkout master
git cherry-pick U
Cherry-picking only creates new commits and does not rewrite history, so it's always safe even if you later push to another repository.
You shouldn't rebase in this situation, since clearly other people have seen commits C through T.
As Greg said, you can use git-cherry-pick
to get just U; but, this will create a new commit with the same diff but a different ID. If you want to get all commits in release-to-customerA into release-to-customerB and master, you can use git-merge
like so:
git checkout release-to-customerB
git merge release-to-customerA
git checkout master
git merge release-to-customerA
Though cherry-picking will work, I'm not sure why you'd want to. It creates duplicate commits, which can cause problems if you ever want to merge. Indeed, this appears to be a case where you want to merge!
(bugfixB, releaseA)
--------------------- Y (master)
/ /
U---X (releaseB) /
/ / /
A---B---C---D---E ... S---T
Note that I added a branch name bugfixB - this is a very general idea. The commit U
should be made on a branch whose purpose is to fix B (it could be several commits). That branch should then be merged into all branches which need the bugfix - in this case, releaseA, releaseB, and master.
git checkout -b bugfixB <SHA1 of B>
# fix things, add changes
git commit
# for each branch...
git checkout releaseA
git merge bugfixB
git checkout releaseB
git merge bugfixB
git checkout master
git merge bugfixB