Rebasing/duplicating feature branch to an older release

Question

I want to backport commits from one branch to one older branch. How should I do this? I know I could for example cherry-pick each commit one by one, but what would be the simplest way to do this?

From this:

___(a)__(b)__(c)__(d)__(e)__(f)__(g) <- master
    \    \             /
     \    (1)__(2)__(3) <- feature
      \
       (x)__(y)__(z) <- old release

To this:

___(a)__(b)__(c)__(d)__(e)__(f)__(g) <- master
    \    \             /
     \    (1)__(2)__(3) <- feature
      \
       (x)__(y)__(z)__(1)__(2)__(3) <- old release with feature

Answer 1

First, let's consider what a normal "rebase" onto the release branch would do here:

• git doesn't know that master is involved, so sees only two branches: a feature with commits a-b-1-2-3 and a release with commits a-x-y-z
• the common branch point is therefore a, so the commits to be rebased will be b-1-2-3
• the new branch will end up as a-x-y-z-b-1-2-3, inserting commit (b) which in practice may be a large chunk of master

Luckily, the git rebase command has a form with three arguments, which the manual page summarises as:

git rebase --onto <newbase> <upstream> <branch>

But would perhaps better be explained as:

git rebase --onto <new-parent> <old-parent> <branch>

In your example:

• <newbase> / <new-parent> would be commit (z): the point you want to graft commits onto
• <upstream> / <old-parent> would be commit (b): the point where the commits you're interested in currently branch from (the current parent of the first commit you're interested in)
• <branch> would be the name of the feature branch which currently points to (3), and which will end up pointing to the new rebased history instead

You can leave off the last argument, and it will just use whatever branch is currently checked out; if specified, it should be a branch name. The other two arguments can be anything that identifies a commit - a branch name, a tag name, or just a commit hash.

Answer 2

You can run the cherry-pick command with a range for example git cherry-pick b..3. I would recommend this way if you don't want to change the branch pointer.

https://git-scm.com/docs/git-cherry-pick#git-cherry-pick-ltcommitgt82308203