Rebase feature branch onto another feature branch

Question

I have two (private) feature branches that I'm working on.

a -- b -- c                  <-- Master
     \     \
      \     d -- e           <-- Branch1
       \
        f -- g               <-- Branch2

After working on these branches a little while I've discovered that I need the changes from Branch2 in Branch1. I'd like to rebase the changes in Branch2 onto Branch1. I'd like to end up with the following:

a -- b -- c                  <-- Master
           \
            d -- e -- f -- g <-- Branch1

I'm pretty sure I need to rebase the second branch onto the first, but I'm not entirely sure about the correct syntax and which branch I should have checked out.

Will this command produce the desired result?

(Branch1)$ git rebase --onto Branch1 Branch2

Solution 1

1. Switch to Branch2

   git checkout Branch2
   

2. Apply the current (Branch2) changes on top of the Branch1 changes, staying in Branch2:

   git rebase Branch1
   

Which would leave you with the desired result in Branch2:

a -- b -- c                      <-- Master
           \
            d -- e               <-- Branch1
           \
            d -- e -- f' -- g'   <-- Branch2

You can delete Branch1.

Solution 2

Note: if you were on Branch1, you will with Git 2.0 (Q2 2014) be able to type:

git checkout Branch2
git rebase -

See commit 4f40740 by Brian Gesiak modocache:

rebase: allow "-" short-hand for the previous branch

Teach rebase the same shorthand as checkout and merge to name the branch to rebase the current branch on; that is, that "-" means "the branch we were previously on".

Solution 3

I know you've already accepted the answer, but if you want to do exactly what you asked for (add Branch2's commits on top of Branch1 while staying on Branch1) you can do this:

git checkout Branch1
git cherry-pick master..Branch2

You'll end up with this.

a -- b -- c                      <-- Master
           \
            d -- e -- f' -- g'   <-- Branch1 (current)
           \
            f -- g               <-- Branch2

This will cherry-pick each of the commits on Branch2 in order onto Branch1. Then you can delete Branch2.

Solution 4

I know you asked to Rebase, but I'd Cherry-Pick the commits I wanted to move from Branch2 to Branch1 instead. That way, I wouldn't need to care about when which branch was created from master, and I'd have more control over the merging.

a -- b -- c                  <-- Master
     \     \
      \     d -- e -- f -- g <-- Branch1 (Cherry-Pick f & g)
       \
        f -- g               <-- Branch2

View more solutions

Comments

[Arjen]

Thanks! When deleting the branch after rebasing I get a message that the branch is not fully merged. I assume I can safely ignore this message and force the delete?

[sasikt]

It should not show any error if you have rebased properly. Make sure that all your commits in the branch1 which is to be deleted is present in branch2 and delete branch1

[Maksymilian Wojakowski]

In case Branch1 changes, you will get into conflicts. Before merging them by hand try "git rebase --skip". If you merge those changes by hand by fully accepting all changes made in the Branch1, you would encounter on "git rebase --continue" the message "No changes - did you forget to use 'git add'?". In such case, also issue "git rebase --skip"

[sthzg]

nice, but also a bit dangerous. sometimes verbosity wins. but then again, I also like Java... (-:

[tomasz_kusmierczyk]

didn't he want to have all changes in Branch1?

[1252748]

This seems like the opposite of what he wanted, no?

[eel ghEEz]

Indeed, @tomasz_kusmierczyk and @1252748, and I got confused myself, too. But then I realized that performing git rebase while staying in Branch1 will rewrite Branch1 history to have Branch1's changes on top of those copied from Branch2. That will result in the following commit order, a - b - f - g - c' - d' - e'.

[a3y3]

@tomasz_kusmierczyk and 1252748, this is not the opposite of what he want, this is EXACTLY what he wanted. Branch names don't matter, you can always change them.

[Nadav]

@a3y3 Branch names DO matter. What if you want to rebase a branch that has an open PR? You can't do it using this method, can you?

[Smar]

This is very useful. I had some commits on top of another (local) branch, not yet pushed to git. I used git cherry-pick mybranch...origin/mybranch to pick those commits to current branch.

[Chris Perry]

This won't work if you're pulling one feature branch into another feature branch. For that, use: git cherry-pick <current-branch>..<other-branch>