What's the difference between git reset --mixed, --soft, and --hard?

Question

I'm looking to split a commit up and not sure which reset option to use.

I was looking at the page In plain English, what does "git reset" do?, but I realized I don't really understand what the git index or staging area is and thus the explanations didn't help.

Also, the use cases for --mixed and --soft look the same to me in that answer (when you want to fix and recommit). Can someone break it down even more? I realize --mixed is probably the option to go with, but I want to know why. Lastly, what about --hard?

Can someone give me a workflow example of how selecting the 3 options would happen?

Bukovina

@Clow answer is pretty good but one may be interested in taking a look at this question, too. – Phyllisphylloclade

Note to self: In general, soft: stage everything, mixed: unstage everything, hard: ignore everything up to the commit I'm resetting from. – Tenacious

See also Bob Kern's additional comments about this – Depersonalization

another good article by David Zych with clear explanation - davidzych.com/difference-between-git-reset-soft-mixed-and-hard – Denunciatory

For those who'd like to see a concrete example with animated visuals, I've put together an explanation of git reset here. – Coprophagous

I added this comment as I didn't find explanation for soft and mixed resets difference in this thread. >>>> The use case for soft and mixed commits is different in a sense that if all you want to do is just a re-commit differently, then you have to do a soft reset. If you want to fix/change the code and then re-commit, you have to do a mixed reset. – Eventful

Note: git reset means git reset --mixed! – Painless

Answer 1

When you modify a file in your repository, the change is initially unstaged. In order to commit it, you must stage it—that is, add it to the index—using git add. When you make a commit, the changes that are committed are those that have been added to the index.¹

git reset changes, at minimum, where the current branch² is pointing. The difference between --mixed and --soft is whether or not your index is also modified. So, if we're on branch master with this series of commits:

- A - B - C (master)

HEAD (the current commit) is C³ and the index matches C (assuming we haven't staged any changes with git add).

When we run git reset --soft B, master (and thus HEAD, indirectly) now points to B, but the index still has the changes from C; git status will show them as staged. So if we run git commit at this point, we'll get a new commit with the same changes as C.

(If we did have staged changes before the reset, those will still be in the index and git commit would commit those changes in addition to the changes from C.)

---

Okay, so starting from here again:

- A - B - C (master)

Now let's do git reset --mixed B. (--mixed is the default option, so this is equivalent to git reset B). Once again, master and HEAD point to B, but this time the index is also modified to match B. If we run git commit at this point, nothing will happen since the index matches HEAD. We still have the changes in the working directory, but since they're not in the index, git status shows them as unstaged. To commit them, you would git add and then commit as usual.

(This time, if we had staged changes before the reset, those changes will be removed from the index, but the files themselves will still contain any changes that were made.)

---

And finally, --hard is the same as --mixed (it changes your HEAD and index), except that --hard also modifies your working directory. If we're at C and run git reset --hard B, then the changes added in C, as well as any uncommitted changes you've made, will be removed, and the files in your working copy will match commit B. Since you can permanently lose changes this way, you should always run git status before doing a hard reset to make sure your working directory is clean or that you're okay with losing your uncommitted changes.

---

In each of the above cases, we specified a commit (B) to reset to. If you don't provide one, it uses HEAD as the default. git reset --soft with no commit specified doesn't do anything (it makes the current branch point to where it was already pointing), but it can be useful for the other two modes. git reset --mixed (or just git reset) updates the index to match the current commit, which has the effect of unstaging any changes that have been added but not committed; git reset --hard does the same, plus it removes any changes in your working directory so that all your files match the latest commit on your current branch. (Again, since those changes are permanently lost, you should be careful when doing a hard reset.)

---

¹ The index is also referred to as the "staging area". You can think of it as another copy of all the files in the repository. When a branch is checked out, the index is updated so that all its files match the contents of that branch. When you git add a file, any changes you made to that file are copied to the index, and when you git commit, the contents of the index are turned into a commit and added to the current branch.

² HEAD is how Git refers to the commit that is currently checked out. HEAD (in most cases) points to a specific branch, called the current branch, and that branch points to a specific commit.

³ Because HEAD points to master and master points to C. Whenever we add or remove a commit on the current branch, the commit that HEAD refers to changes not because HEAD itself changed, but because the branch that HEAD points to was updated to point to that commit.

Clow

In other words, --soft is discarding last commit, --mix is discarding last commit and add, --hard is discarding last commit,add and any changes you made on the codes which is the same with git checkout HEAD – Onder

One addition: git reset --hard isn't permanent, you can recover the change using reflog – Dorthydortmund

@eventualEntropy You can recover any committed changes with the reflog; uncommitted changes that are removed with reset --hard are gone forever. – Clow

What happens if I have local modifications in my working tree before the reset --mixed? Will it overwrite my local changes or will it merge them? – Plural

@Robert Neither; --mixed changes your index but not your working directory, so any local modifications are unaffected. – Clow

What about if a file being reset I'd also modified on my working copy? Well it merge them? (Referring to mixed) – Plural

May be helpful for visual people who use git on terminal with colour: 1.'git reset --soft A' and you will see B and C's stuff in green (staged) 2.'git reset --mixed A' and you will see B and C's stuff in red (unstaged) 3.'git reset --hard A' and you will no longer see B and C's changes anywhere (will be as if they never existed) – Loaves

May be worth explaining what happens if you reset more than just one commit back. – Malkamalkah

Thx! Let me check my understanding. Suppose I'm on this series of commits: - A - B - C (master) May I expect in every situation that 1. doing git reset --mixed B followed by doing git add followed by git commit brings me back to the original situation? 2. doing git reset --mixed A followed by doing git add followed by git commit brings me back to the original situation? 3. doing git reset --soft B followed by git commit brings me back to the original situation? 4. doing git reset --soft A followed by git commit brings me back to the original situation? – Remde

@user1933930 1 and 3 will leave you with - A - B - C′, where C′ contains the same changes as C (with different timestamp and possibly commit message). 2 and 4 will leave you with - A - D, where D contains the combined changes of B and C. – Clow

@Clow if you use Intellij or another product from Jetbrains, you can recover uncommitted code too using the local history. Saved my skin a few times that way! – Theme

if you have a local and remote repo up to date and on say revision C, and you revert to revions A using --hard, does this revert the local repo, the remote repo (origin) or both? If only local, how does one rever the remote origin also? I.e. what is the complete list of steps to revert the last X commits? – Maskanonge

i think you confused soft and mixed. following @timhc22's input down below I could reproduce it in sourcetree – Lopeared

@mkarasek, based on what you wrote I'm tempted to say that the following could be a definition of the --soft option: --soft is the option to git reset such that a successive plain git commit leaves you on a new commit which has the same content of the commit from which you resetted. Am I wrong? – Wagoner

minor suggestion re "HEAD points to C" under your first code block: HEAD doesn't point to C. It points to master. If it pointed directly to C, you would be in a detached head state and git reset --soft B wouldn't have any effect on master. – Templin

If I understand this correctly, even a mixed reset can lead to loss of data, albeit in rare situations maybe. Assume you make some changes, add them to the index and then delete these changes from the working directory. Now a mixed reset will (semi-)permanently delete your changes, since they only existed in the index. Those changes can only be recovered from Git's object storage. (until Git's GC run, that is). – Disrepair

that visualization is a bit misleading imo. it implies that doing git checkout <SHA> will update the history so the latest commit is the one before <SHA> and that the modifications of <SHA> are removed from history and staging but are still in the working directory and ready to be git add and git commitd. When in actuality, all that happens is that the history's latest commit is changed to <SHA>, no? – Odontoid

Answer 2

In the simplest terms:

• --soft: uncommit changes, changes are left staged (index).
• --mixed (default): uncommit + unstage changes, changes are left in working tree.
• --hard: uncommit + unstage + delete changes, nothing left.

Avrilavrit

best answer because the answer uses technical terms to provide a complete answer that is also the most concise – Intrusive

When I've committed a file (unpushed) and I have a newly created untracked file, then git reset --hard does nothing? Only when I stage the untracked file, it removes it from my working directory. – Humming

@Nikhil Can you explain where this answer is wrong? – Birthwort

@NedBatchelder None of the point is correct: As uncommit never happens when these commands are used. – Schnapps

@Nikhil Perhaps what you mean is that the original commit still exists, which is true. But the branch has been changed so that the commit is no longer part of the branch. Do we agree on that? – Birthwort

@NedBatchelder Yes, I agree with that. Shall I delete my comment? – Schnapps

For beginnners: The answer is neither wrong nor true. It implies that resets are only made to previous commits. However, you can reset to any commit in the tree anywhere. You have to understand that reset moves the HEAD and the associated branch pointer and does not actually modify the tree of commits (as implied by "uncommit"). However, git will, for reasons of efficiency, remove commits after a while (default 90 days) when they are unreachable, i.e. not in the history of any branch. Think about what this implies if you want to go exploring... (also git prune and gc may delete commits) – Leicester

Does "uncommit" mean "move the HEAD"? This answer makes it sounds as if the previous commit was deleted, which I don't believe is the case at all. Plus, you can use RESET to pull changes from the current HEAD, which doesn't uncommit anything. – Ringe

This is the only readable answer. It's accurate: you can't improve it in any way that helps my everyday work. I don't care about implementation trivia. – Eliathas

add a note that --mixed is the default, and then you get an A+ – Josh

Answer 3

Three types of regret

A lot of the existing answers don't seem to answer the actual question. They are about what the commands do, not about what you (the user) want — the use case. But that is what the OP asked about!

It might be more helpful to couch the description in terms of what it is precisely that you regret at the time you give a git reset command. Let's say we have this:

A - B - C - D <- HEAD

Here are some possible regrets and what to do about them:

1. I regret that B, C, and D are not one commit.

git reset --soft A. I can now immediately commit and presto, all the changes since A are one commit.

2. I regret that B, C, and D are not two commits (or ten commits, or whatever).

git reset --mixed A. The commits are gone and the index is back at A, but the work area still looks as it did after D. So now I can add-and-commit in a whole different grouping.

3. I regret that B, C, and D happened on this branch; I wish I had branched after A and they had happened on that other branch.

Make a new branch otherbranch, and then git reset --hard A. The current branch now ends at A, with otherbranch stemming from it and containing B, C, and D.

(Of course you could also use a hard reset because you wish B, C, and D had never happened at all.)

Fabiolafabiolas

In regret 3, you could have used a soft reset instead of a hard one, right? When checking out the new branch, both the index and the working directory would match commit D. Correct me if I’m wrong. By the way, if we do a mixed reset, then after checking out the new branch we would have to add the working directory to the index and then both the index and working directory would match commit D. Right? – Restaurateur

@PedroMachado I don't see it that way at all, sorry. – Fabiolafabiolas

You honestly should consider a career in technical teaching. This was an excellent way to frame/teach the "I f*cked up, now what do" scenario most people are in when searching for this answer. Props friend. – Cruzeiro

@Cruzeiro That's in fact the career I did have. – Fabiolafabiolas

This is great. As said, the OP wanted use cases, and here they are. – Behavior

To @PedroMachado 's question: yes, you could have used a soft reset, but then it is more complicated. In (3), you want the main branch to end at A, without any further work in the working directory or index. You want it "clean" with B, C, and D gone. But you also want the otherbranch to have B, C, and D, exactly with the same changes in the same order. By using git reset --hard A after creating a new branch, you have (1) created otherbranch, which looks like main before removing B, C, and D, and (2) removed B, C, and D from main branch. – Behavior

I do not immediately get the 1. with reset --soft. Where ist my pointer afterwards? Isn't always the goal to have the current branch pointing to A, no matter wether using soft mixed or hard? By looking at other explanations with soft I am only pointing to A but B<-C<-D<-HEAD are just untouched. – Sorcerer

@DirkSchumacher Try it and see for yourself. – Fabiolafabiolas

Answer 4

Please be aware, this is a simplified explanation intended as a first step in seeking to understand this complex functionality.

May be helpful for visual learners who want to visualise what their project state looks like after each of these commands:

Given: - A - B - C (master)

---

For those who use Terminal with colour turned on (git config --global color.ui auto):

git reset --soft A and you will see B and C's stuff in green (staged and ready to commit)

git reset --mixed A (or git reset A) and you will see B and C's stuff in red (unstaged and ready to be staged (green) and then committed)

git reset --hard A and you will no longer see B and C's changes anywhere (will be as if they never existed)

---

Or for those who use a GUI program like 'Tower' or 'SourceTree'

git reset --soft A and you will see B and C's stuff in the 'staged files' area ready to commit

git reset --mixed A (or git reset A) and you will see B and C's stuff in the 'unstaged files' area ready to be moved to staged and then committed

git reset --hard A and you will no longer see B and C's changes anywhere (will be as if they never existed)

Loaves

This is misleading, at best: your answer reads as if git reset only changes the look of git status's output. – Unorthodox

I see your point, but disagree because as a visual learner, seeing how my project 'looked' after using the 3 commands finally helped me understand what they were doing! – Loaves

I saw it more of a 'git for dummies' kind of idea to help people ease in to what is actually happening. Can you think of how it could be improved so as not to be misleading – Loaves

No, we don't need to change this answer. It provides a handy "cheat sheet". Think about it: soft=green, mixed=red, hard=nothing(means gone)! How easy to remember! For those newbies who don't even understand what those color really mean, they know too little about git, and they are going to take hard lessons down the road anyway, and that is NOT @unegma 's fault! BTW, I just upvote this answer to counteract that previous downvote. Good job, @unegma! – Strained

This served as a great supplemental summary to better understand the inner workings as I read them elsewhere. Thank you! – Malkamalkah

Then do git reset HEAD <filename(s) to uncommit> – Macedoine

Answer 5

All the other answers are great, but I find it best to understand them by breaking down files into three categories: unstaged, staged, commit:

• --hard should be easy to understand, it restores everything
• --mixed (default) :
  1. unstaged files: don't change
  2. staged files: move to unstaged
  3. commit files: move to unstaged
• --soft:
  1. unstaged files: don't change
  2. staged files: dont' change
  3. commit files: move to staged

In summary:

• --soft option will move everything (except unstaged files) into staging area
• --mixed option will move everything into unstaged area

Ordinarily

Answer 6

In these cases I like a visual that can hopefully explain this:

git reset --[hard/mixed/soft] :

So each one affects different scopes:

1. Hard => WorkingDir + Index + HEAD
2. Mixed => Index + HEAD
3. Soft => HEAD only (index and working dir unchanged).

Cubbyhole

Answer 7

You don't have to force yourself to remember differences between them. Think of how you actually made a commit.

1. Make some changes.

2. git add .

3. git commit -m "I did Something"

Soft, Mixed and Hard is the way enabling you to give up the operations you did from 3 to 1.

• Soft "pretended" to never see you have did git commit.
• Mixed "pretended" to never see you have did git add .
• Hard "pretended" to never see you have made file changes.

Brassica

Answer 8

Here is a basic explanation for TortoiseGit users:

git reset --soft and --mixed leave your files untouched.

git reset --hard actually change your files to match the commit you reset to.

In TortoiseGit, The concept of the index is very hidden by the GUI. When you modify a file, you don't have to run git add to add the change to the staging area/index. When simply dealing with modifications to existing files that are not changing file names, git reset --soft and --mixed are the same! You will only notice a difference if you added new files or renamed files. In this case, if you run git reset --mixed, you will have to re-add your file(s) from the Not Versioned Files list.

Hurst

This answer is very unclear re the difference between soft and mixed. and is even dismissive in stating it. This following answer is more clear on that. #2530560 – Pappus

As a user of Github Desktop which also has the same behaviour, this answer gives me some clarity of why I keep confused about --mixed and --soft. – Kenn

Answer 9

mkarasek's Answer is great, in simple terms we can say...

• git reset --soft : set the HEAD to the intended commit but keep your changes staged from last commits
• git reset --mixed : it's same as git reset --soft but the only difference is it un stage your changes from last commits
• git reset --hard : set your HEAD on the commit you specify and reset all your changes from last commits including un committed changes.

--soft and --mixed are a bit similar, the only difference is, if you want to keep your changes in staging area use --soft, and if you don't want your changes in staging area use --mixed instead.

Reassure

Answer 10

Before going into these three option one must understand 3 things.

1) History/HEAD

2) Stage/index

3) Working directory

reset --soft : History changed, HEAD changed, Working directory is not changed.

reset --mixed : History changed, HEAD changed, Working directory changed with unstaged data.

reset --hard : History changed, HEAD changed, Working directory is changed with lost data.

It is always safe to go with Git --soft. One should use other option in complex requirement.

Abbotsun

Answer 11

There are a number of answers here with a misconception about git reset --soft. While there is a specific condition in which git reset --soft will only change HEAD (starting from a detached head state), typically (and for the intended use), it moves the branch reference you currently have checked out. Of course it can't do this if you don't have a branch checked out (hence the specific condition where git reset --soft will only change HEAD).

I've found this to be the best way to think about git reset. You're not just moving HEAD (everything does that), you're also moving the branch ref, e.g., master. This is similar to what happens when you run git commit (the current branch moves along with HEAD), except instead of creating (and moving to) a new commit, you move to a prior commit.

This is the point of reset, changing a branch to something other than a new commit, not changing HEAD. You can see this in the documentation example:

Undo a commit, making it a topic branch

          $ git branch topic/wip     (1)
          $ git reset --hard HEAD~3  (2)
          $ git checkout topic/wip   (3)

1. You have made some commits, but realize they were premature to be in the "master" branch. You want to continue polishing them in a topic branch, so create "topic/wip" branch off of the current HEAD.
2. Rewind the master branch to get rid of those three commits.
3. Switch to "topic/wip" branch and keep working.

What's the point of this series of commands? You want to move a branch, here master, so while you have master checked out, you run git reset.

The top voted answer here is generally good, but I thought I'd add this to correct the several answers with misconceptions.

Change your branch

git reset --soft <ref>: resets the branch pointer for the currently checked out branch to the commit at the specified reference, <ref>. Files in your working directory and index are not changed. Committing from this stage will take you right back to where you were before the git reset command.

Change your index too

git reset --mixed <ref>

or equivalently

git reset <ref>:

Does what --soft does AND also resets the index to the match the commit at the specified reference. While git reset --soft HEAD does nothing (because it says move the checked out branch to the checked out branch), git reset --mixed HEAD, or equivalently git reset HEAD, is a common and useful command because it resets the index to the state of your last commit.

Change your working directory too

git reset --hard <ref>: does what --mixed does AND also overwrites your working directory. This command is similar to git checkout <ref>, except that (and this is the crucial point about reset) all forms of git reset move the branch ref HEAD is pointing to.

A note about "such and such command moves the HEAD":

It is not useful to say a command moves the HEAD. Any command that changes where you are in your commit history moves the HEAD. That's what the HEAD is, a pointer to wherever you are. HEADis you, and so will move whenever you do.

Templin

"moving the branch ref": good point. I had to update https://mcmap.net/q/12024/-practical-uses-of-git-reset-soft. – Haphazard

Perhaps change “move the branch ref HEAD is pointing to” to “move the branch ref (away?) from where HEAD is currently pointing to”? Am I understanding it correctly? – Restaurateur

@PedroMachado nope. You move the branch ref that HEAD is pointing to, and you go along with it, so HEAD goes along with it. See https://mcmap.net/q/12032/-what-is-head-in-git – Templin

This should have more votes: it gives a use case with the master and WIP branches which, I'm guessing, really gets at the heart of things for the OP and others just coming to learn about Git. – Behavior

Answer 12

--mixed vs --soft vs --hard:

--mixed:

   Delete changes from the local repository and staging area.

   It won't touch the working directory.

   Possible to revert back changes by using the following commands.

     - git add

     - git commit

   Working tree won't be clean.

--soft:

    Deleted changes only from the local repository.

    It won't touch the staging area and working directory.

    Possible to revert back changes by using the following command.

     - git commit.

    Working tree won't be clean

--hard:

    Deleted changes from everywhere.

    Not possible to revert changes.

    The working tree will be clean.

NOTE: If the commits are confirmed to the local repository and to discard those commits we can use:

 `git reset command`.

But if the commits are confirmed to the remote repository then not recommended to use the reset command and we have to use the revert command to discard the remote commits.

Modality

you can revert git reset --hard by a git reflog – Macdonell

Answer 13

A short answer in what context the 3 options are used:

To keep the current changes in the code but to rewrite the commit history:

• soft: You can commit everything at once and create a new commit with a new description (if you use torotise git or any most other GUIs, this is the one to use, as you can still tick which files you want in the commit and make multiple commits that way with different files. In Sourcetree all files would be staged for commit.)
• mixed: You will have to add the individual files again to the index before you make commits (in Sourcetree all the changed files would be unstaged)

To actually lose your changes in the code as well:

• hard: you don't just rewrite history but also lose all your changes up to the point you reset

Snowmobile

I dont get soft and mixed in this case. If you have to commit, then what was reverted? are you commiting the revert, or recommiting the changes (so getting back to the original state?) – Maskanonge

Recommitting the changes. There will be no reverse commit. – Snowmobile

@JohnLittle: The only difference between soft and mixed resets is that soft doesn’t change the index but mixed makes the index match the target commit (the one referred to in the reset command). Both soft and mixed (and hard) change the branch and HEAD pointers to point to the target commit. A hard reset, besides changing the two pointers and changing the index to match the target commit (like mixed does), also changes the working directory to match the target commit. – Restaurateur

Answer 14

Basic difference between various options of git reset command are as below.

• --soft: Only resets the HEAD to the commit you select. Works basically the same as git checkout but does not create a detached head state.
• --mixed (default option): Resets the HEAD to the commit you select in both the history and undoes the changes in the index.
• --hard: Resets the HEAD to the commit you select in both the history, undoes the changes in the index, and undoes the changes in your working directory.

Firetrap

Answer 15

--soft: Tells Git to reset HEAD to another commit, so index and the working directory will not be altered in any way. All of the files changed between the original HEAD and the commit will be staged.

--mixed: Just like the soft, this will reset HEAD to another commit. It will also reset the index to match it while working directory will not be touched. All the changes will stay in the working directory and appear as modified, but not staged.

--hard: This resets everything - it resets HEAD back to another commit, resets the index to match it, and resets the working directory to match it as well.

The main difference between --mixed and --soft is whether or not your index is also modified. Check more about this here.

Corneliacornelian

Good answer. It’s only missing to mention the change in the branch pointer. – Restaurateur

Answer 16

• All types of reset change the HEAD in the repo. Additionally...
• git reset --soft <B> moves the changes from commits removed from repo into the index, merging in any that were there already.
• git reset --hard <b> loses the changes in the working tree and the index.
  It is the only one to change the working tree.

Compagnie

Answer 17

Mo Ali has put it in simplest terms and here's another simple explanation:

--soft: reset HEAD pointer to previous commit

--mixed:--soft + delete added changes

--hard: --mixed + recover working tree file changes (CAREFUL！）

Barley

Answer 18

I’m not a git expert and just arrived on this forum to understand it! Thus maybe my explanation is not perfect, sorry for that. I found all the other answer helpful and I will just try to give another perspective. I will modify a bit the question since I guess that it was maybe the intent of the author: “I’m new to git. Before using git, I was renaming my files like this: main.c, main_1.c, main_2.c when i was performing majors changes in order to be able to go back in case of trouble. Thus, if I decided to come back to main_1.c, it was easy and I also keep main_2.c and main_3.c since I could also need them later. How can I easily do the same thing using git?” For my answer, I mainly use the “regret number three” of the great answer of Matt above because I also think that the initial question is about “what do I do if I have regret when using git?”. At the beginning, the situation is like that:

A-B-C-D (master)

1. The first main point is to create a new branch: git branch mynewbranch. Then one get:

A-B-C-D (master and mynewbranch)

2. Let’s suppose now that one want to come back to A (3 commits before). The second main point is to use the command git reset --hard even if one can read on the net that it is dangerous. Yes, it’s dangerous but only for uncommitted changes. Thus, the way to do is:

Git reset --hard thenumberofthecommitA

or

Git reset --hard master~3

Then one obtains: A (master) – B – C – D (mynewbranch)

Then, it’s possible to continue working and commit from A (master) but still can get an easy access to the other versions by checking out on the other branch: git checkout mynewbranch. Now, let’s imagine that one forgot to create a new branch before the command git reset --hard. Is the commit B, C, D are lost? No, but there are not stored in any branches. To find them again, one may use the command : git reflog that is consider as “a safety command”( “in case of trouble, keep calm and use git reflog”). This command will list all commits even those that not belong to any branches. Thus, it’s a convenient way to find the commit B, C or D.

Deva