3

I have two branches: Master and Feature.

I made some changes to Master and wanted to copy them into Feature. So I merged Master into Feature. Apparently, that was the wrong thing to do because now prior changes to Feature appear in Master. 

What I expected:
A - B - - - - E - G   [master]
     \         \
      C - D - - F - H [feature]

What it looks like now:
                      G   [master] 
                     /
A - B - C - D - E - F - H [feature]

Here's the fun part: I merged Master into Feature twice before noticing the problem, and I've made additional commits to both branches. How do I undo the merges or make it so Master is unaffected by Feature's commits?

sharoz
  • 6,157
  • 7
  • 31
  • 57
  • This is not an answer, but a suggestion for the future. Instead of merging `master` into `feature`, use `git rebase` instead. For example, once you're on the `feature` branch (`git checkout feature`), you would call `git rebase master`, which would apply changes that are in `master` but not yet in `feature`. See [this page](http://git-scm.com/book/ch3-6.html) for more info on merging and rebasing. – hunch_hunch Oct 09 '14 at 17:29
  • 1
    Your ASCII graphs are unclear/ambiguous. Please read the remarks at the top of [this answer of mine](http://stackoverflow.com/questions/25488138/move-initial-commits-off-master-to-another-branch-in-git/25490288#25490288), and correct your graphs so we know exactly where your branches are pointing. – jub0bs Oct 09 '14 at 17:32
  • 1
    @hunch_hunch Stated like that this is dangerous advice. What if the feature branch is pushed somewhere and other people work on it? Rebasing still is an advanced feature. One should master simple merging first. – musiKk Oct 09 '14 at 17:44
  • 1
    Please include the commands you typed to perform the merges. Your graphs still don't make sense based on what you described. – Andrew C Oct 09 '14 at 17:52
  • @Jubobs ok, it looks inconsistent, but I think the format copies that example now – sharoz Oct 09 '14 at 17:53
  • @sharoz The first one kind of makes sense, but the second one doesn't. Besides, you shouldn't label branches on the left. – jub0bs Oct 09 '14 at 17:55
  • @Jubobs. This representation should be more accurate. – sharoz Oct 09 '14 at 18:09
  • @sharoz That's much better. So, just to be clear: you want to obtain the state described by the first graph, correct? – jub0bs Oct 09 '14 at 18:29
  • @Jubobs Yes. Correct. – sharoz Oct 09 '14 at 18:31
  • @sharoz For completeness, you should add the commands that you ran from commit B onwards. How did you reach the state labeled "What it looks like now"? – jub0bs Oct 09 '14 at 18:33
  • @Jubobs I used sourcetree, so I don't know. But I had the latest feature commit checked out and "merged Master into Feature". – sharoz Oct 09 '14 at 18:39
  • 2
    If you merged Master into Feature, then you would not be seeing changes from Feature appearing in Master. I suspect you did something else entirely (although quite possibly inadvertently and/or without realizing it...). – twalberg Oct 09 '14 at 19:50
  • @twalberg Yes; I can't make sense of what happened. One possible scenario is that commit `E` was created on the wrong branch (`feature` instead of `master`), then `master` was merged (fast-forward) in `feature`. However, that still wouldn't explain commit `F`. – jub0bs Oct 10 '14 at 06:15

1 Answers1

0

Given the tree you drew in your question, you want to undo commits C, D, and F from master. To accomplish this, from the command prompt type:

git checkout master
git revert C
git revert D
git revert F
David Deutsch
  • 17,443
  • 4
  • 47
  • 54