Why do I get conflicts when I do git revert?

That’s actually not what revert does. Revert doesn’t “take you back to” that commit and pretend that subsequent commits didn’t happen. It applies a logical negation of a single commit – and that commit alone – leaving subsequent commits in place.

Let’s say you have some initial commit of some file – let’s call it commit #1 for simplicity – and the file looks like this:

One
Two
Three
Four

Now let’s say you have a commit #2 that changes one line:

One
2
Three
Four

And finally, commit #3 that changes a different line:

One
2
Three
4

If you try to revert commit #2, it will undo only the line changed in that commit, and leave the changes introduced in commit #3, so the result will be:

One
Two
Three
4

Now, if there was a subsequent commit that had changed the same line as the commit that you’re trying to revert, then you’ll have a conflict. For example, let’s say you have a commit #4 that also changed the second line:

One
TWO
THREE
4

Now if your HEAD is commit #4 and you try to revert commit #2, you will have a conflict. Revert expects to take second line back – to undo the changes made in commit #2. So it expects the second line to currently be 2, and it will then revert it to what it was in the previous commit, setting it to Two.

However, that expectation was invalidated, since commit #4 had also changed it. So you have a conflict.

If your goal isn’t to revert at all, but to get back to commit #1 and ignore all the changes that have gone on since then, then you want to reset instead of revert.

git reset --hard 1 

Leave a Comment