Don't use "git reset" to revert committed changes. Well... do, but be careful... The word "revert" is problematic here, and I suppose that "reset" is a bit awk

Don't use "git reset" to revert committed changes. Well... do, but be careful... The word "revert" is problematic here, and I suppose that "reset" is a bit awkward, too. In git, a "revert" means you are creating a new commit that is the reverse of the commit you want to undo. The two commits exist and effectively cancel each other out. The danger here is potentially thinking "git reset" will revert a committed and pushed change (sometimes people push early). In general, this is probably not what you intend. "git reset" moves branch pointers around. So when you "git reset HEAD^", you are really saying you want to move your current branch and HEAD (the thing that indicates where you are in the tree) to the prior commit. The current commit still exists but can be ignored. Speculation now, but I think it is right... This same understanding applies to the "unstaging". The staging area is another tree node, and when you say "git reset HEAD" on the staged file, you are moving it back into the HEAD state. One note on unstaging and other resetting... You can reset --soft or --hard. --soft (default) means that you want to dirty up your directory with the differences between the file's current revision and the reset revision. This is useful if you are cleaning up an unpublished branch (using reset to undo). "git reset" could be called "git move-my-branch-tag" and make more sense.