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

Flue

To answer your question, I would create a test repository, create the commit structure you showed and try the command you showed. But I think you can do that yourself, so I am not going to do it :) – Mcnally

Thanks. I was so bent on getting this right the first time that it didn't occur to me that I could easily test this myself :-) – Flue

I thought so, that's why I posted that comment :) Everytime I do something I am not sure it will do what I think it does, I create a test repository and perform my tests there. Or, I create a copy of my real repository and perform the tests on the copy. – Mcnally

Note: Git 2.0 will introduce a shortcut for this kind of rebase: git rebase -. see my answer below – Eaglewood

Minor note: The answers here give branch2 as the result. The OP wanted branch1. Or I missed something? – Snipe

Edit needed: If you need "changes from Branch2 in Branch1" then you would end up with "a -- b -- c // f -- g -- d -- e" ... you need changes from Branch1 in Branch2? – Withy

Answer 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.

Vannie

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? – Flue

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 – Vannie

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" – Dayan

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

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

Indeed, @Hydrastine 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'. – Yamen

@Hydrastine 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. – Ascariasis

@Ascariasis 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? – Montreal

Answer 2

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

git checkout Branch2
git rebase -

The - as rebase parameter in this case means 'the branch we were previously on'. 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".

Use this feature with caution, as it is less explicit and a small mistake could lead to a messed up state.

Eaglewood

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

Answer 3

This solution should do exactly what was asked for (add Branch2's commits on top of Branch1 while staying on Branch1):

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.

Matless

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. – Rutherfordium

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> – Silica

Answer 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

Kelcie

Answer 5

Am I misunderstanding this question? My instinct was to use rebase's --onto flag like so:

git rebase --onto branch1 master branch2

Before rebase:

* 6263580 (HEAD -> branch2) add g
* c802c88 add f
| * c80cfb0 (branch1) add e
| * aea5708 add d
| * 2e522fe (master) add c
|/  
* 0613527 add b
* e2a0c4d add a

After rebase:

* 7f6a363 (HEAD -> branch2) add g
* 4cbab60 add f
* c80cfb0 (branch1) add e
* aea5708 add d
* 2e522fe (master) add c
* 0613527 add b
* e2a0c4d add a

This makes it explicit and its clear what set of commits are getting rebased onto what

Broadus