What is difference between 'git reset --hard HEAD~1' and 'git reset --soft HEAD~1'?
Solution 1
git reset
does know five "modes": soft, mixed, hard, merge and keep. I will start with the first three, since these are the modes you'll usually encounter. After that you'll find a nice little a bonus, so stay tuned.
Let's assume you have a repository with a history akin to this:
7e05a95 (HEAD -> main) Update a
e62add5 Update b
ca9ae0a Update a
9b6060d Add c
eebe372 Add b
947586a Add a
Where the latest commit (7e05a95
) contains these changes:
diff --git a/a b/a
index b66ba06..28b68e2 100644
--- a/a
+++ b/a
@@ -1 +1 @@
-new content
+new new content
Now what would happen when you run git reset
with the various different modes? Let's find out!
soft
When using git reset --soft HEAD~1
you will remove the last commit from the current branch, but the file changes will stay in your working tree. Also the changes will stay on your index, so following with a git commit
will create a commit with the exact same changes as the commit you "removed" before.
How would this look like in practice? Like this:
> git reset --soft HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: a
As you see the changes in file a
are on the index, and ready to be committed again.
mixed
This is the default mode and quite similar to soft. When "removing" a commit with git reset HEAD~1
you will still keep the changes in your working tree but not on the index; so if you want to "redo" the commit, you will have to add the changes (git add
) before commiting.
In practice the result might look like this:
> git reset --mixed HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: a
no changes added to commit (use "git add" and/or "git commit -a")
The changes of file a
are still there but they're not on the index.
hard
When using git reset --hard HEAD~1
you will lose all uncommited changes and all untracked files in addition to the changes introduced in the last commit. The changes won't stay in your working tree so doing a git status
command will tell you that you don't have any changes in your repository.
Tread carefully with this one. If you accidentally remove uncommited changes which were never tracked by git
(speak: committed or at least added to the index), you have no way of getting them back using git
.
A practical example might look like this:
> git reset --hard HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
nothing to commit, working tree clean
As you can see, no changes remain. Assuming you also had some uncommitted changes in the file b
these would be lost too!
> echo 'some uncommitted changes' > b
> git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: b
no changes added to commit (use "git add" and/or "git commit -a")
> git reset --hard HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
nothing to commit, working tree clean
Bonus
keep
git reset --keep HEAD~1
is an interesting and useful one. It only resets the files which are different between the current HEAD
and the given commit. It aborts the reset if one or more of these files has uncommited changes. It basically acts as a safer version of hard
.
Let's revisit the example from before, where you had some uncommitted changes in b
:
> echo 'some uncommitted changes' > b
> git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: b
no changes added to commit (use "git add" and/or "git commit -a")
> git reset --keep HEAD^ # Assuming HEAD points at 7e05a95
> git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: b
no changes added to commit (use "git add" and/or "git commit -a")
You removed the changes in file a
but retained the uncommitted changes in file b
!
So to reiterate: "hard" will remove all changes while "keep" only removes changes from the reset commit(s).
Each of these modes is explained in depths in the git reset documentation.
Note
When doing git reset
to remove a commit the commit isn't really lost, there just is no reference pointing to it or any of it's children. You can still recover a commit which was "deleted" with git reset
by finding it's SHA-1 key, for example with a command such as git reflog
.
Solution 2
Git reset has 5 main modes: soft, mixed, merged, hard, keep. The difference between them is to change or not change head, stage (index), working directory.
Git reset --hard will change head, index and working directory.
Git reset --soft will change head only. No change to index, working directory.
So in other words if you want to undo your commit, --soft should be good enough. But after that you still have the changes from bad commit in your index and working directory. You can modify the files, fix them, add them to index and commit again.
With the --hard, you completely get a clean slate in your project. As if there hasn't been any change from the last commit. If you are sure this is what you want then move forward. But once you do this, you'll lose your last commit completely. (Note: there are still ways to recover the lost commit).
Solution 3
This is a useful article which graphically shows the explanation of the reset command.
https://git-scm.com/docs/git-reset
Reset --hard can be quite dangerous as it overwrites your working copy without checking, so if you haven't commited the file at all, it is gone.
As for Source tree, there is no way I know of to undo commits. It would most likely use reset under the covers anyway
Solution 4
This is the main difference between use git reset --hard and git reset --soft:
--soft
Does not touch the index file or the working tree at all (but resets the head to , just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.
--hard
Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.
Related videos on Youtube
mesutali
Fresh Electronics Engineer needs software answers but not selfish one :)
Updated on October 15, 2021Comments
-
mesutali over 2 years
I tried to undo my commit in git. Is it dangerous to use
git reset --hard HEAD~1
?What is the difference between different options for
git reset
?-
M.M almost 10 yearspossible duplicate of Whats the difference between git reset --mixed, --soft, and --hard?
-
-
ThanksForAllTheFish almost 10 years+1 for the link to the official documentation. I would also mention
git reset --help
which explains quite well (in my opinion) the five modes, or at least the two asked by the OP. -
Matthieu Moy about 9 yearsI disagree that these 3 are the ones we should usually use. They are the 3 that were first available so people talk about these 3 more, but
--hard
is almost never the right thing to do, as--keep
is much safer and applies to most of the senarios where--hard
works. Training your fingers to use--keep
might save you, one day ... -
Sascha Wolf about 9 yearsI didn't try to suggest that we should use them, merely that these are commands one encounters most of the time. Feel free to edit the answer as you see fit.
-
englealuze about 6 yearsTo add a bit more details, after git reset --soft HEAD~1, using git commit --reuse-message=HEAD@{1} to reuse the last commit with the preserved old index as shown here stackoverflow.com/a/25930432/2883282
-
Sascha Wolf over 5 years@MatthieuMoy, three years late but I added a section on
keep
. ;) -
Kiki Jewell about 5 yearsLink is broken. Likely this is the current version: git-scm.com/docs/git-reset
-
elvis over 4 yearsHow can I undo the last commit? Please help. If I use git reset --soft HEAD~1 I receive: fatal: ambiguous argument 'HEAD~1': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'
-
Sascha Wolf over 4 years@elvis see this question. It implies that your repositories
HEAD
points to a non-existing ref. This happens for example in a freshly created repository. In case the linked question doesn't help, you might want to ask your own question. Comments are meant for clarification and not "further questions". 🙂 -
Qasim almost 4 yearsThis is what I was looking for. Succinct and accurate.