What is HEAD?
HEAD is a reference to the last commit in the currently check-out branch.




Difference Between a git reset and git revert
It’s important to understand the difference between resetting vs reverting commits when using Git.

The git reset command undoes commits by removing previous commits from the repository and resetting the Git HEAD to an earlier commit. Some Git history might be lost by doing this, depending on what option is used.

The git revert command undoes commits by creating a new commit that represents an earlier state of the repository. No Git history will be lost by doing this.

Already pushed changes and someone else pulled those changes? You should not use git reset to undo changes, you should use git revert as described in the Git rollback commit guide instead.

Using the git reset Command to Undo a Commit
For the following examples, assume our local Git tree looks like this:

        X
        |
A - B - C

The X represents our local, uncommitted change to our Git HEAD, indicated by C.

To undo the commit named “C “due to a mistake, we can run a git reset command.

Depending on file tracking needs, you’ll want to use the git reset command with different flags.

Case 1: Use git reset and Remove Files From the Staging Area
We can use the git reflog command to see our Git history.

We can use git ls-files to see the currently staged files for our project:

$ Git reflog
f326d13 HEAD@{0}: commit: Added C
358d535 HEAD@{1}: commit: Added B
00b61d5 HEAD@{2}: commit (initial): Added A

$ Git ls-files
A
B
C
X
To keep any tracked files since commit C, but remove them from the Git index, you can run:

Git reset HEAD~1
You can use the Git shorthand of HEAD~1 to remove the commit one commit before HEAD.
If you used HEAD~5, this would remove the commit that is five commits before HEAD.
Changes to the Git index, also called the “staging area,” will be lost, so the Git tree would now be:

  X
  |
A-B
Which we can confirm with these commands:
$ Git reflog
358d535 HEAD@{0}: reset: moving to HEAD~1
f326d13 HEAD@{1}: commit: Added C
358d535 HEAD@{2}: commit: Added B
00b61d5 HEAD@{3}: commit (initial): Added A

$ Git ls-files
A
B

$ Git status
On branch master
Untracked files:
  (use "Git add ..." to include in what will be committed)

        C
        X

When just using git reset with no flags, we don’t remove any files; they are just un-staged:

$ ls
A  B  C  X
You do end up removing the log entry for the commit you reset, however:

$ Git log
commit 358d535bc5e06730e61d272be34a6d0e568f42af
Author: User <user@example.com>
Date:   Tue Feb 10 13:54:55 2015 -0500

    Added B

commit 00b61d53fe06ee672fa0497b175fb7bd89e26b72
Author: User <user@example.com>
Date:   Tue Feb 10 13:54:55 2015 -0500

    Added A
Case 2: Use git reset –soft and Preserve Changes to Files
If you use the –soft flag, any changes to tracked files and the Git index are preserved:

1
Git reset --soft HEAD~1
Any files that were staged remain so, and no files are physically removed:

$ Git ls-files
A
B
C
X

$ ls
A  B  C  X

$ Git status
On branch master
Changes to be committed:
  (use "Git reset HEAD ..." to unstage)

        new file:   C
        new file:   X
Using the –soft flag, you still end up removing the log entry for the commit you reset.

Case 2: Use git reset –hard and Remove All Changes to Files
If you use the –hard flag, any changes to tracked files and the Git index are lost:

1
2
$ Git reset --hard HEAD~1
HEAD is now at 3bf1b55 Added B
All files after the commit you reset to are un-staged and physically removed:

$ Git ls-files
A
B

$ ls
A  B

$ Git status
On branch master
nothing to commit, working directory clean
You again remove the Git log entry for the commit that you reset.

Try to Use git revert When Commits Are Already Pushed
As stated above, if you’ve already pushed your changes and someone else pulled in those changes, you should not use git reset to undo changes, use git revert instead.

However, if you really want to, you can apply the same steps as in the previous section to delete some previous Git commits.

After that, you can do a git push -f to use the force option. Again, this is not recommended, because it can create serious conflicts between the various repository states of other Git users.