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 ab-1-2-3 and a release with commits axyz
• 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 axyzb-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