28

I have two branches, master and feature1. I was working on feature1 when I realized that I needed to work on something else unrelated. Unfortunately, I forgot to branch from the master, and instead created my feature2 branch from feature1. Now I want to merge feature2 into master, but cannot because there are parts of feature1 in that branch.

How do I remove the feature1 commits from the feature2 branch? Does it involve rebasing?

I feel that if I could change the starting reference point of feature2 to be where master is, that might help, but have no idea how.

EDIT:

Thank you for the answers! I tried rebasing according to @Mark's solution, but realized that the history is more complicated than I originally thought. feature 2 has been merged into other feature branches, and master was merged into feature2 at one point. There are also additional commits on master that are not related to feature2 Everything is still local.

Really, my history is more like this:

A - B - C - D - - - - - - - - - - - - - L - M  master  
            |                          
            |               - I - J - K  feature2                  
            \              /           \
             - E - F - G - H - - - - - -N - O - P  feature1

And what I want is this:

A - B - C - D - - - - - - - - - -  L - M  master
            |\                          
            |  - - - - - I - J - K  feature2                  
            \                     \
              - E - F - G - H - - - N - O - P  feature1

I have also tried:

git rebase --onto 1524b824cfce5856a49e feature1 feature2
// 1524b824cfce5856a49e == D

But this just sets the branch name feature 2 pointing at 1524, and leaves commits I, J, K with their original parents.

Andrew
  • 3,052
  • 3
  • 27
  • 37
  • Be careful if you're using a shared repository. If the commits you're trying to change are "pushed" somewhere you're going to run into problems when other people pull if you mess around with commit history. If you're using something like GitHub I don't think it will allow changes to the commit history. – Dave Lancea Aug 31 '11 at 16:08
  • Thanks for the warning! Luckily, everything is still local. – Andrew Aug 31 '11 at 16:47
  • So you want `I` branched off of `D` and than merged back into `master` on the commit after `D`? Unless I'm missing something, that doesn't make much sense. – Andy Aug 31 '11 at 16:58
  • No, that was me screwing up :) I actually want K merged back into master. – Andrew Aug 31 '11 at 17:07
  • 1
    So basically all you want to do is remove E-F-G-H from _feature2_? – Andy Aug 31 '11 at 17:12
  • 1
    Yes. I want to keep the history of the two features separate, because feature2 is ready to be merged into master, but feature1 is not. – Andrew Aug 31 '11 at 17:17

2 Answers2

29

If it's only you working on your feature2 branch and you haven't shared it with other people, it's fine to rebase that branch before merging. You could do the following, for example:

git checkout feature2
git rebase --onto master feature1 feature2

... which will rewrite your feature2 branch, leaving it so that it consists of all the commits in feature2 since it was branched from feature1, but reapplied onto master. I suggest you use gitk --all or a similar git history viewer afterwards to check that the result of this operation is what you want.

Incidentally, this is exactly the scenario used to explain --onto in the git rebase documentation - see the paragraph beginning:

Here is how you would transplant a topic branch based on one branch to another, to pretend that you forked the topic branch from the latter branch, using rebase --onto. [...]


Updated in response to more material in the question:

Starting with your history, which looks like this:

A - B - C - D - - - - - - - - - - - - - L - M  master  
            |                          
            |               - I - J - K  feature2                  
            \              /           \
             - E - F - G - H - - - - - -N - O - P  feature1

You can get what you want by doing the following:

git checkout feature2
git rebase --onto D H feature2

This will leave you with history that looks like:

A - B - C - D - - - - - - - - - - - - - - - - - - - L - M  master  
            |\
            | \ - I' J' K' feature2       I - J - K                    
            \                           /           \
             - - - - - - - E - F - G - H - - - - - -N - O - P  feature1

Before creating the merge that you want in feature1, you should note down the SHA1sum of O and P. (I'm assuming N is just a normal merge, and not an "evil merge".)

Then do a hard reset to move feature1 back to H:

git checkout feature1
git rest --hard H

Then you should have the history:

A - B - C - D - - - - - - - - - - - - - - - - - - - L - M  master  
            |\
            | \ - I' J' K' feature2
            \
             - - - - - - - E - F - G - H feature1

Now you apparently want to merge K' into feature1:

git merge K'

A - B - C - D - - - - - - - - - - - - - - - - - - - L - M  master  
            |\
            | \ - I' - J' - - - - - - - K' feature2
            \                             \
             - - - - - - - E - F - G - H - Z feature1

And finally you can cherry-pick the old O and P onto feature1 with:

git cherry-pick O
git cherry-pick P

... to leave:

A - B - C - D - - - - - - - - - - - - - - - - - - - L - M  master  
            |\
            | \ - I' - J' - - - - - - - K' feature2
            \                            \
             - - - - - - - E - F - G - H - Z - - O' - P' feature1
Mark Longair
  • 385,867
  • 66
  • 394
  • 320
  • Thank you for the response! I made an edit to add further details. – Andrew Aug 31 '11 at 16:47
  • I looked at my history, and I was wrong in my diagram (now updated). feature2 is not merged into master. Nor is feature1. – Andrew Aug 31 '11 at 17:20
  • ! If people are trying to help here, it's really important to get the information you post correct, otherwise you're just wasting their time. Your question has undergone two revisions that totally changed its meaning, and thus the answer that would be required. Regardless, I've updated my answer to match your third version... – Mark Longair Aug 31 '11 at 17:31
  • Yes, you are absolutely correct, and I apologize. Initially, I wanted to keep the question simple, but in doing so oversimplified to the point where it no longer matched the situation. I also wasn't sure of what to actually ask, since I wasn't even sure of what path/tool would get me to what I wanted. Thank you for your patience and responses, they have been extremely thorough. – Andrew Aug 31 '11 at 18:24
  • No problem, and sorry for being irritable. Unfortunately, this kind of branch rewriting is really rather specific to the exact topology of the commit graph. To be honest, once you're in that situation, I'd probably try to avoid this kind of rewriting, and just merge each branch back to master when they're in a working state that adds some new feature, even if the history is a bit tangled. – Mark Longair Aug 31 '11 at 19:35
  • After playing with this for this long, I think I'm in agreement! But, you're answer was very helpful in understanding how I might go about fixing this. The actual topology is much more complicated than I described here. – Andrew Aug 31 '11 at 20:00
  • `rebase --onto master feature1 feature2` was exactly what I was looking for. Thanks so much. Git rocks! – phatmann Mar 21 '13 at 19:23
2

If you don't mind that feature2 is merged back in on P instead of M, here is a relatively simple solution.

  1. Rebase I-J-K onto D, look at the section title "more interesting rebases
  2. Rebase O-P onto H. same way as done in step 1
  3. Finally merge feature2 into feature1 with git merge feature2 while having feature1 checked out.

If you want K merged into a particular commits, the rebasing gets a little trickier.

Andy
  • 38,684
  • 13
  • 64
  • 66
  • 1
    Could you give me an example of how to rebase feature1 to remove the cherry-picked commits? – Andrew Aug 31 '11 at 16:48
  • [Here](http://stackoverflow.com/questions/495345/git-removing-selected-commits-from-repository) is a SO question that answers how to do that. – Andy Aug 31 '11 at 16:51
  • I was initially wrong, in that neither feature1 or feature2 are merged into master. So this should be a bit more easy. – Andrew Aug 31 '11 at 17:26
  • One more update with another solution based on your clarifications. – Andy Aug 31 '11 at 17:41