6

From time to time we can run across issues where we commit a feature branch to our baseline and discover in some situations it can go horribly wrong, so the change needs to be reverted, without losing all the other commits done since then. However, someone needs to continue working on the original branch.

I don't want to use git rebase on the main line to change history (because that'd cause all sorts of issues all by itself), but when I do git revert on the main line then as soon as git merge is run on the branch, to pick up any other changes done to the system, then all the work done disappears.

What can I do to keep the changes on the branch intact?

Tom Tanner
  • 9,244
  • 3
  • 33
  • 61
  • Is this a merge commit you're reverting? If so, take a look at http://stackoverflow.com/questions/1078146/re-doing-a-reverted-merge-in-git – John Szakmeister Jul 23 '13 at 10:20
  • 1
    Ah, I see the problem, you're merging the mainline into your branch. I think the link I provided above will do the trick for you. You just have to "revert the revert" on your branch. – John Szakmeister Jul 23 '13 at 10:22
  • ohh. ok, some of the stuff referred to in there looks helpful – Tom Tanner Jul 23 '13 at 13:24

3 Answers3

5

I assume you don't want to do any rebases and resets, this is merge-only approach.

Suppose you have two branches master and feature. So, you've decided merge the feature into master:

$ git merge feature

Now, you have all your feature changes on the master. I assume the most difficult scenario - there are commits made after the merge on both branches. But, suddenly you see that nothing works of feature, all is broken and decide to revert it. Your history is (you could see it with git log --graph feature master):

* commit 838f29fda2333bdbfc0d1be44d2387e6119dc4e8
| 
|     f3
|    
| * commit 58d1e3f0e032cc77d4ab2bbf0bdfe6407b96b7e6
| | 
| |     m3
| |     
| *   commit afb600fe382befe095f9b8a6e9eef98be25c929b
| |\  Merge: 5cddc52 8660a59
| |/  
|/|   
| |       Merge branch 'feature'
| |   
* | commit 8660a59eeb13f9b3447846ba6977140f7c86c7a4
| | 
| |     f2
| |   
* | commit 6f76e2288d69808b97981340198fd8044ab47630
| | 
| |     f1
| |   
| * commit 5cddc528de424a01d1d18552ddea93435618e2f7
| | 
| |     m2
| |   
| * commit fa6ebb76f9f0308f7dcd1148503534668fa15358
|/  
|   
|       m1
|  
* commit 4e3aa05d6f46eb14bbbc253a42325e9a53a3393e

Notice the commits f3 and m3 which have been done after merge. So, you need carefully delete only changes from feature appeared in the master.

To do it you could revert the merge commit on the master, keeping master's base (the parameter -m1). To achieve it I create a new branch based on the merge point and revert in it:

$ git checkout -b feature-revert afb600fe
$ git revert -m1 HEAD

Now, we have a reverted changes on the branch feature-revert. Now it is simple just put it into master by merging:

$ git checkout master
$ git merge feature-revert

So, at the moment the master doesn't have anything from the feature. However, if later you want to re-merge the feature, all reverted changes will be lost in master, as they were merged and reverted.

To solve the issue you should revert the revert (he-he) and merge it back to the feature:

$ git checkout feature-revert
$ git revert HEAD
$ git checkout feature
$ git merge feature-revert

I suppose we don't need the branch anymore, as we merged it already, but you could keep it if you want:

$ git branch -d feature-revert

You should be aware, that merging it back brings all changes from master into feature which usually normal workflow.

Now, after fixes made in feature you could merge it again into master as usual anytime.

kan
  • 28,279
  • 7
  • 71
  • 101
1

When you git revert your changes, it creates a new commit, whose tree doesn't have those changes.

The changes aren't removed though, their original commits still exist.

So, just:

  • git revert your merge commit on master (remember to select the correct parent). Now master doesn't have the broken code introduced from your feature branch
  • fix the feature branch
  • revert the first revert on master. This will re-introduce the broken state of the feature as you merged it originally
  • merge the feature-branch fixes over

See here (or the same file in your local git docs if installed) for more details.

You history ends up looking like:

 --- a -- ... -- Mi ... ~Mi ... ~~Mi -- Mx  [master]
      \         /                      /
       f1 ... fi -- fj ........ x -- fx     [feature]

where Mi is your original merge from the feature branch, ~Mi is the reversion when you noticed the problem, fj .. fx are subsequent fixes to the feature branch, ~~Mi is the reversion of ~Mi, etc.

Useless
  • 64,155
  • 6
  • 88
  • 132
  • But once I've git reverted the master, I can't merge the master back into the feature branch, which I need to do. – Tom Tanner Jul 23 '13 at 13:10
  • Yes you can, just _revert the reversion first_. It's the third point in the bullet list above, is denoted `~~Mi` in the graph (and described in the paragraph below), and is shown just under the quote from Linus in the linked document. – Useless Jul 23 '13 at 13:16
  • Couldn't one also recreate the branch, as per the linked document, via `git rebase --no-ff a`, where a is the branch point? – Hasturkun Jul 23 '13 at 15:47
  • Yes, that works too. It wasn't clear from the question whether new work was still ongoing on the feature branch (`fj..fx`) in addition to the bug fix, and rebasing a branch while people are working on it is evil. – Useless Jul 23 '13 at 16:50
0

Have you tried doing the git revert on the feature branch and then merging that back into master?

That way the baselines stay the same and you can continue working on your feature branch.

Abizern
  • 146,289
  • 39
  • 203
  • 257
  • How would I keep the changes if I did that? Wouldn't that remove the changes? If I reverted the reversion immediately, would subsequent merges work or would they delete the changes again? – Tom Tanner Jul 23 '13 at 09:23