Some git commands are dangerous because they will destroy data with no possibility of recovery. Pro Git named them “WD unsafe commands.” I know of two WD unsafe commands:
reset --hard [commit]
checkout (commit) [file]
Is there an explicit list of all WD unsafe commands? Really I want to avoid the situations where wasn’t a chance for me to figure out what sort of changes will be done and which untracked files may affect.
First, you need to regularly backup your git repository (actually, any important data -in particular your source code- should be backed up; hardware is failing, people are making mistakes). A popular way of doing that could be to often git push --all to some external repository, e.g. on github.
But if you discipline yourself -and you really should- to git commit and git push quite often (e.g. typically after every hour of development at most, or when fixing a single bug or adding a small feature), you practically won't lose much data. You'll always be able to come back to any state after any commit (and that is the most powerful feature of git). So in the worst case you lose everything after your last commit (& push), which is not a big deal, since you have the habit to git commit (& git push) quite often.
If you don't have a network connection, still git commit very often, but do git push -on the network, into a remote repository- for backup purposes (at least daily).
Indeed, a git checkout would overwrite any non-committed file (notice the terminology: for subversion, svn checkout is not doing a similar thing: the svn checkout & git checkout commands look similar, but are very different).
The important thing is to git commit (and git push) very often (and that is your responsibility). Of course use git branches.
Use very often the git status command. Be careful about the files you are ignoring in .gitignore (which you should manage with git). Once in a while (perhaps weekly, and certainly before any important software release), consider perhaps git clone-ing your repository (in some fresh directory) and build your software in the cloned repository to be sure that everything required is there.
I want to know those before losing any important thing accidentally.
So if you git commit (& push) often, you won't lose any important data. At most you'll lose everything you did since your last git commit. Not a big deal. Of course you should never touch "manually" your .git/ hidden directory used for the git repository. And you should git push daily to some remote repository, in particular to avoid losing your work if your hardware breaks (e.g. if you drop or burn or get stolen your laptop).
Don't expect a software system to decide when you should git commit. That is your responsibility and you should do that very often (but at appropriate times). The nice thing about git is that a git commit is really very cheap and quick. So you should use it very often.
Though you asked about "WD unsafe commands", your question implies being concerned about losing work in general. To Basile's answer I would add that there is a class of "commit unsafe" commands. That is, commands that will delete a commit. All the committing in the world won't save you if you delete those commits. Pushing might, but then you'll have quite the fun time attempting to reconcile the conflicts with your backup remote.
Two off the top of my head:
git commit --amend
git rebase # And pretty much any argument or subcommand to it.
That said, those two commands are extremely useful. While git commit --amend technically deletes your latest commit, it applies the entire patch set including your most recent staged set to the new one. In other words, it keeps this history:
$ git log --oneline
c5526a4 One Single Change
From becoming this:
$ git log --oneline
5563dba ...And Another Part
c5526a4 Crap, Forgot a Part
a5c809b One Single Change
Rebasing has a lot of use, like turning those 3 commits above into a single commit a week later. But there are a lot of implications to doing all this when routinely committing and pushing. See this really good answer. Rebasing allows you to just entirely delete commits without squashing them into another, so it's definitely one of the more potentially unsafe commands.
You might also find a way of using git gc after commits have disappeared from all references, including the reflog, though I have to say I'm not confident about the internals at work here.
