Undoing
Reverting is different from resetting in that reverts usually create new history while resets usually remove existing history.
The changes of a revert are applied to the current state of the repository, and, if committed, results in a new repository state descending from the current one.
Reverts are safe to publish even if they revert a previously published commit, and, in fact, are the correct way of dealing with the undoing of published commits.
Resetting, on the other hand, represents (a possibly selective) "rewind" to a previous state in the history "starting again" from there.
Resets should never be committed if they undo commits that have been published or pushed to remote repositories, as this would result in invalid object histories and commit ID's in the remote repositories.
Reverting
- git revert rev
-
Revert the changes introduced by rev, and record a new commit that records it. This does not do the same thing as similarly named commands in other VCS's such as "svn revert" or "bzr revert".
- git checkout path(s)
-
Re-checkout file or files specified by path(s), overwriting any local changes. This is most similar to "svn revert".
- git checkout -- path(s)
-
As above, but use this syntax if you have a branch or tag with the same name as a path given in path(s).
- git checkout rev path(s)
-
Re-checkout file or files specified by path(s) to version specified by rev (which may be specified using a SHA1 commit ID, branch name, or tag), overwriting any local changes.
- git checkout -f
-
Throw away all local changes since last commit, restoring working tree to last committed state (plus untracked files) and clearing index. Unlike "
git reset --hard
", does not move HEAD, and so will not, for example, cleanly forget about a failed merged: use "git reset --hard
" for this.
Resetting
- git reset
-
Resets the index (i.e., removes all changes staged for commit) but does not modify the working tree (i.e., the changes in the files are preserved), and does not change HEAD.
- git reset rev -- path(s)
-
Restores file or files specified by path(s) to
revision specified by rev, without changing HEAD.
- git reset rev
-
Sets the current HEAD to the commit specified by rev (which may be specified using a SHA1 commit ID, branch name, or tag), and resets the index but not the working tree (i.e current changes in the working tree are preserved).
- git reset --soft rev
-
Sets the current HEAD to the commit specified by rev, and does not modify the working tree, but keeps changes in the index for editing. For example, if something was forgotten or omitted in the previous commit, "git reset --soft HEAD^" will undo the last commit, and keep all changes in the index for editing and the next commit.
- git reset --hard
-
Throw away all local changes since last commit, restoring working tree to last committed state (plus untracked files) and resetting both index and HEAD.
- git reset --hard rev
-
Sets the current HEAD to the commit specified by rev, and changes the working tree to mirror the new HEAD (plus untracked files). For example, "git reset --hard ORIG_HEAD" will undo the most recent successful merge and any changes that occurred after. Useful for forgetting about the merge just done. If there are conflicts (the merge was not successful), use "git reset --hard" instead.