203

Is it possible to unstage the last staged (not committed) change in git? Suppose there were a lot of files in the current branch, some staged, some not. At some point, some foolish programmer accidentally executed:

git add -- .

...instead of:

git checkout -- .

Can this programmer now unstage his last changes with some magical git command? Or should he have committed before experimenting in the first place?

Septagram
  • 9,425
  • 13
  • 50
  • 81
  • Heh. We got a useful question and answer out of this though. – steveha May 16 '15 at 02:58
  • 2
    possible duplicate of [Undo 'git add' before commit](http://stackoverflow.com/questions/348170/undo-git-add-before-commit) – Jim Fell Jun 26 '15 at 15:11
  • I believe it is not the duplicate. OP in the other question is asking for a way to undo this or remove these files from the commit. I want(ed) precisely and only to undo the changes that were added with the last `git add` command, especially for the files that already had staged changes, and had some changes which were to be undone, not staged. Can't say the other question is not related though. – Septagram Jun 30 '15 at 09:08
  • 2
    Perhaps he should have /been/ committed before experimenting in the first place. – android.weasel Jul 20 '15 at 10:31
  • @android.weasel yes, that was many years ago... – Septagram Jul 21 '15 at 10:36

10 Answers10

311

You can use git reset. This will 'unstage' all the files you've added after your last commit.

If you want to unstage only some files, use git reset -- <file 1> <file 2> <file n>.

Also it's possible to unstage some of the changes in files by using git reset -p.

thameera
  • 9,168
  • 9
  • 37
  • 38
  • 3
    How sad. I guess there's something wrong in my committing practices after all. Accepting this answer, because you mentioned `-p` switch. Thanks! :) – Septagram Aug 26 '12 at 20:14
  • Generates (for me) the error: fatal: Failed to resolve 'HEAD' as a valid ref. I haven't committed anything yet (new repo) just done git add . and regretted it. I don't want to reset the entire add, just one directory. git reset -- dir/*.* generates the error above. – Francis Davey Jan 23 '14 at 17:51
  • ... Ah, I see what is happening for me. I did not have anything for HEAD to point to yet and so git reset failed (because it operates on the HEAD). – Francis Davey Jan 23 '14 at 18:04
44

You cannot undo the latest git add, but you can undo all adds since the last commit. git reset without a commit argument resets the index (unstages staged changes):

git reset
knittl
  • 246,190
  • 53
  • 318
  • 364
  • 2
    "You cannot undo the _latest_ git add": Wow, this is surprising and potentially painful. Is there a definitive source for this? Also, is there a good reason it should be so? Thanks! – Andrew Moylan Jun 08 '16 at 02:45
  • @AndrewMoylan: well, there's no _automatic_ way to do so. You can always `reset` a single file, or use `reset -p` to unstage a specific hunk. – knittl Jun 08 '16 at 05:28
16

So the real answer to

Can this programmer now unstage his last changes with some magical git command?

is actually: No, you cannot unstage just the last git add.

That is if we interpret the question as in the following situation:

Initial file:

void foo() {

}

main() {
    foo();
}

First change followed by git add:

void foo(int bar) {
    print("$bar");
}

main() {
    foo(1337);
}

Second change followed by git add:

void foo(int bar, String baz) {
    print("$bar $baz");
}

main() {
    foo(1337, "h4x0r");
}

In this case, git reset -p will not help, since its smallest granularity is lines. git doesn't know that about the intermediate state of:

void foo(int bar) {
    print("$bar");
}

main() {
    foo(1337);
}

any more.

stanm
  • 3,201
  • 1
  • 27
  • 36
  • 2
    I plussed because as a new git user, that's a really important distinction that highlights what my friends describe as "having good checkin hygiene"... my personal experience - it was described as "carpooling" (bad!). – benc Mar 12 '18 at 16:03
6

You could use git reset (see docs)

davids
  • 6,259
  • 3
  • 29
  • 50
4

You can use

git reset

to undo the recently added local files

 git reset file_name

to undo the changes for a specific file

ireshika piyumalie
  • 2,226
  • 22
  • 22
3

At date git prompts:

  1. use "git rm --cached <file>..." to unstage if files were not in the repo. It unstages the files keeping them there.
  2. use "git reset HEAD <file>..." to unstage if the files were in the repo, and you are adding them as modified. It keeps the files as they are, and unstages them.

At my knowledge you cannot undo the git add -- but you can unstage a list of files as mentioned above.

theGiallo
  • 146
  • 6
3

If you want to remove all added files from git for commit

git reset

If you want to remove an individual file

git rm <file>
BSB
  • 2,270
  • 17
  • 26
2
  • Remove the file from the index, but keep it versioned and left with uncommitted changes in working copy:

    git reset head <file>
    
  • Reset the file to the last state from HEAD, undoing changes and removing them from the index:

    git reset HEAD <file>
    git checkout <file>
    
    # If you have a `<branch>` named like `<file>`, use:
    git checkout -- <file>
    

    This is needed since git reset --hard HEAD won't work with single files.

  • Remove <file> from index and versioning, keeping the un-versioned file with changes in working copy:

    git rm --cached <file>
    
  • Remove <file> from working copy and versioning completely:

    git rm <file>
    
Faisal
  • 4,591
  • 3
  • 40
  • 49
0

Depending on size and scale of the difficultly, you could create a scratch (temporary) branch and commit the current work there.

Then switch to and checkout your original branch, and pick the appropriate files from the scratch commit.

At least you would have a permanent record of the current and previous states to work from (until you delete that scratch branch).

Philip Oakley
  • 13,333
  • 9
  • 48
  • 71
0

I would suggest to use:

git rm -r --cached <your_dir> or git rm --cached <your_file>

It reverts your

git add <your_dir_or_your_file>

back, while keeping the files as they are.

moorhuhn
  • 311
  • 2
  • 2