Its not that it's conceptually hard, the interface just sucks. Like how is "checkout" both for switching branches and also for reverting files? And also it's completely counter to what a "checkout" means in every other VCS. It's just bizarre stuff like that. (I love git, but mercurials interface makes way more sense)
git checkout isn't designed to revert files. It's designed to allow you to check out a particular version of a file without changing the branch you're on.
"Reverting a file" is a higher level concept you can build on top of that, but that's not the fault of git checkout. Also arguably to truly revert a file you'd have to follow it up with a git commit.
I would also point out that recent versions of git have added a git switch subcommand because of some of these complaints.
Well TIL after using git for 8 years. And yet 90% of the time what I'm typing is "git checkout --" which has nothing to do with the branch of the file, im just getting rid of something. It's a bad UI when the obscure case is favored over the common one, and believe me I can pick out 100 other cases.
This is interesting. I find myself using checkout to check out individual files extremely rarely. It feels like a bit of an anti-pattern to me. What I do instead is commit the changes I intend to keep, using some interactive form of commit (usually git gui) followed by git reset --hard to remove whatever I don't want to keep.
The underlying rule is never to make destructive changes on a working directory that also has changes I intend to keep. This massively reduces the risk of data loss by accidental fat fingering of a command.
