Reverting the working tree version of a file to match the index version is one of many things git checkout
can do (depending on what args you give it).
Reverting the index version of a file to match the version in the HEAD
commit is one of many things git reset
can do (depending on what args you give it). It is different from the above usage of checkout
in that one changes the index and the other changes the worktree. (There are other checkout
operations that also affect the index; and that's part of the issue that leads to the next point...)
git restore
is a relatively new command that groups these functions together, while "un-grouping" them from the unrelated things those other commands do. The docs push toward using it because it's the newer, more clear way to perform the operations it covers. The operation is equivalent; it's just new porcelain to make git more usable.
I don't know what github has to do with using one command or the other. If there's some way in which you think they're pushing restore
over the others, they'd be right anyway for the reason noted above - that it's the modern way to perform those operations.