is there any difference between `git reset HEAD` and `git reset HEAD~`

I’m currently learning the git reset command.

I was just wondering, what is the difference between git reset HEAD vs git reset HEAD~.

  • Keep a commit locally to clone in Git
  • Edit a commit message in the pushed code
  • How can I change code within a commit to help find a bug?
  • Git: can't commit a file even though I've resolved the conflict
  • git finding duplicate commits (by patch-id)
  • Push file updates to GitHub
  • Are these commands two ways to achieve the same thing? Or there are difference between them that are only observable under certain conditions?

    when I run these two commands on the under the same circumstances, they seem to behave the same, but in order to avoid the what you see is all there is pitfall, I’m asking the question just to be sure.

  • git splitting repository by subfolder and retain all old branches
  • Incredible failure saving a git commit message via emacs in cygwin
  • Solidus vs Spree - which should be used?
  • Git filter-branch with index-filter does not work and remove directories as expected
  • sed: parse git --line-porcelain output
  • Trigger Jenkins job when pushing to a particular git branch
  • 3 Solutions collect form web for “is there any difference between `git reset HEAD` and `git reset HEAD~`”

    They are the same if you only have one commit otherwise HEAD~ will always refer to the first parent of the commit.

    In addition I can suggest some interesting reading for git reset.

    git reset HEAD unrolls to git reset --mixed HEAD. From the documentation for --mixed

    So git reset HEAD~ will unroll to git reset --mixed HEAD~1 which means Reset the HEAD's first parent with the --mixed option

    –mixed
    Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.

    I now refer to the very good blog entry git reset demystified.
    Side Note: From this blog post I finally learned how reset is actually working.

    Now take another second to look at THAT diagram and realize what it did. It still undid your last commit, but also unstaged everything. You rolled back to before you ran all your git adds AND git commit.

    On one hand, git reset COMMIT (equivalent of git reset --mixed COMMIT) means:

    1. Move the HEAD reference to points to COMMIT
    2. Reset the index to the tree of COMMIT

    (git reset is fully explained in Reset Demystified)

    On the other hand:

    • HEAD represents the current commit
    • HEAD~ represents the first ancestor of HEAD

    (The meaning of ~ is explained in the documentation of git revisions, look at the example at the end of the section for better understanding)

    When you combine both:

    • git reset HEAD: simply reset the index
    • git reset HEAD~: move to previous commit and reset index accordingly

    In both cases your working directory will never be impacted.

    running

    git reset HEAD~
    git reset HEAD
    

    the second command has no effect because after the first the new HEAD is previous HEAD~.
    see

    git rev-parse HEAD HEAD~ HEAD^@
    

    Note that git reset HEAD~ can be undone with

    git reset HEAD@{n}
    

    where n can be retrieved with git reflog

    Git Baby is a git and github fan, let's start git clone.