Undo reverting changes in one branch

Viewed 111

I have created a branch branch1 from master.

created a file test1.txt in branch1:

test1.txt

some logic

Then I merged branch1 to master. But I realized that the logic implemented in branch1 is not properly tested. So I have removed the logic in test1.txt and directly committed in master.

Now the file in master will be like this:

test1.txt

removed logic

Then I switched to branch1 and tested the logic. Since the logic looks fine, I didn't make any changes to the files.

When I tried to merge these changes to master, it shows the following message:

Already up to date.

How can I merge these changes to master?

2 Answers

There are several way to do this.

One of them is : on your master branch, revert the commit where you deleted the logic

git revert <sha1>

This will create a new commit, which re-enables said logic.


Or you can simply edit the file by hand, to reenable the logic (you may copy/paste the relevant chunk from the version in branch1), and commit on master.

The problem is that branch1 was already merged into master and you have made no changes in branch1 since then.

There's more than one way to proceed.


One way is simply to checkout branch1 and make some change, even if it is just adding a newline, and add-and-commit. Now you can checkout master and merge branch1 into it again.

I presume, however, that when you do that, you'll get a merge conflict on your file test1.txt. Since you know that the branch1 version is right, you can say

git checkout --theirs test1.txt
git add .
git commit -m'merged branch1 again'

That completes the merge, overwriting test1.txt in master with the incoming version from branch1.


However, that's not what I would actually do. I would have done something completely different when I discovered that issue with the original merge. I would have undone the original merge. Don't make a change in test1.txt in master directly; instead, just turn back the clock to before you made the merge in the first place.

To do so, get onto master, and use git log to find out the SHA of the commit just before the merge. Then say

git reset --hard <SHA>

Poof, the merge is gone; Git has no memory that there was ever a merge. Now checkout branch1 again and test the logic, and if/when it's good, switch to master and perform the merge — which you can now do, because branch1 was never merged into master as far as Git is concerned.

(I like this approach best because the resulting story told by the history is accurate.)

Related