3

I have the following situation:

master A -  B -  E 
                / 
second   C -   D - F

What is the best solution to revert all commits of 'second branch' from master branch?

The 'second' branch has about 70 commits.

kemenov
  • 409
  • 4
  • 13
  • 1
    what do u mean by revert? u don't want the E commit? – TheOneTeam Apr 23 '13 at 16:36
  • i have merged second branch with master and make push. So, now i want to exclude all commits of second branch from my master branch. – kemenov Apr 23 '13 at 16:40
  • 6
    @KitHo Please take the time to write out "you". Chat speak isn't very welcome on Stack Overflow. – user229044 Apr 23 '13 at 16:40
  • @feak Please update you visualization. I cannot understand how the *second* branch can grow into two directions. – JJD Apr 23 '13 at 22:15

3 Answers3

10

You should take a look at an answer I provided for a slightly different question, which involved reverting merge commits. "Reverting Merges vs. Resetting Merges". This will explain how revert works and how reset work with respect to merge commits. In that case someone had already reverted, but had some funky behavior after wanting to undo the revert - so take a look after reading this answer so you can get a full understanding of how it works.

Dont Reset!

Using git-reset after having pushed the commit means you've changed history that other people already have, This is bad. If you reset, you are effectively rewinding history. To push this up you will need to perform a forced push. Other developers will then need to know to use git-fetch followed by git reset --hard origin/master, and they may even need to perform a complicated git rebase --onto if they have new commits after the merge commit you removed. Other wise they will just end up pushing up the same commit you just reset.

It is generally a bad idea to modify history that has already been pushed.

Use Git Revert

Using git revert creates a new commit that negates the content of the merge commit instead of rewinding it. It moves you forward in history rather than modifying history.

git revert E

After reverting that merge commit, you will have the following history...

master A -  B -  E  - G 
                / 
               /
second   C -  D - F

TheG commit represents the revert. That commit "undoes" the changes that the merge introduced. There are issues to be aware of when reverting merge commits. Please read my answer on "Reverting Merges vs. Resetting Merges" to become aware of how it works, and how to undo the revert later.

Community
  • 1
  • 1
eddiemoya
  • 6,713
  • 1
  • 24
  • 34
6

I'm assuming 'E' is a merge commit. There are two simple ways to do this. One is to reset your last commit from branch master:

git checkout master
git reset --hard HEAD^

I don't recommend this, since, this will remove the last commit from your master branch.

Now the second option is to revert the commit:

git checkout master
git revert HEAD -m 1 M

You have to pass the -m option because 'E' is a merge commit. This will create a new commit reverting the changes made. I suggest you try this at a copy of the repository before anything else. Also, if you're working in collaboration with other developers, it is desirable not to rewrite history. The first method rewrites the history, so I suggest you use the second one.

Also, check these links:

how to revert a faulty merge

rewriting history

Hope it helps!

Daniel Noguchi
  • 593
  • 3
  • 7
0

To revert it, it is very easy, commit E is the merge commit from all commit in second branch, what to do is to delete the E (merge commit), then in master branch, there will be no more things from second branch.

  1. git checkout master
  2. git reset --hard HEAD^

Then it is ok.

Everything in second branch will still retain. For master branch, no more things from second branch.

TheOneTeam
  • 25,806
  • 45
  • 116
  • 158
  • 6
    I down voted your answer. You stated that "reverting" is easy, but then you described "resetting". – eddiemoya Apr 23 '13 at 19:56
  • 2
    Down-voted because 'reset' is not the same as 'revert' and since the merge has been pushed, 'reset' is a very bad option. You should be using 'revert' in this case. – Courtney Miles Dec 17 '13 at 02:53
  • It would be good to mention the downside of resetting this way and that it should only be done when you are able to tell that no one has fetched the commit that's being removed, or you can communicate directly with people who have fetched it in order to fix things up in their repos. – bames53 Mar 07 '14 at 19:41
  • 1
    Unfortunate that this answer got accepted, since it's just wrong if you have more commits on master. reset <> revert. – Guntram Blohm Sep 24 '14 at 08:27