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).
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.