Undo committed changes

Question

I learn from a book, called Ryan Hodson - Ry's Git Tutorial, and it says:

Before we undo the changes, we need to return to the master branch. If we didn't, all of our updates would be on some non-existent branch. You should never make changes directly to a previous revision.

What does it mean?

In my case, I'm at the tip of the master branch, and i have to revert to the previous commit

Answer 1

This isn't the most clearly written passage IMO; but after a couple re-reads, I'm pretty sure I've inferred the correct context to understand what it means. (It's the only conceptually-accurate way I can find to interpret this passage, so...)

Presumably if you've been following the tutorial step by step, then you are currently in "detached HEAD state". This occurs when you directly check out a commit - usually because you've checked out a commit further back in your branch's history. For example if you have

A -- B -- C <--(master)

and you checkout the B commit, by saying something like

git checkout master^

then this puts you in detached HEAD state. You could represent this as

A -- B -- C <--(master)
     ^
    (HEAD)

It looks like the tutorial leads you to do this to examine a change, which it now determines you want to undo.

So it's saying that if you don't first checkout master, and you make another commit, you'll end up with

A -- B -- C <--(master)
      \
       D 
       ^
       (HEAD)

You'd still be in detached HEAD state, and D would not be "reachable" from any ref. This isn't always wrong (as the tutorial suggests), but it isn't typically right. You'd have to take further steps to prevent D from just getting discarded.

The tutorial uses the phrase "make changes directly to a previous revision", but that's not a precisely accurate description of what you'd be doing. It would be more accurate to say that you typically would avoid staging new changes while in detached HEAD state (but probably the author finds that phrasing too technical/confusing for git novices).