How do I discard unstaged changes in Git?

Question

How do I discard changes in my working copy that are not in the index?

See also http://stackoverflow.com/questions/22620393/various-ways-to-remove-local-git-changes — Cees Timmerman, Feb 04 '16 at 17:11
`git-clean` only removes untracked files from the working tree https://git-scm.com/docs/git-clean — Yega, Sep 15 '16 at 12:29
To clarify Asenar's comment above, `git-clean -df` can be dangerous. It will delete local untracked files (e.g. covered by a .gitignore) Read all below carefully and consider git checkout . instead — jacanterbury, Oct 07 '16 at 08:05
'git clean -df ' Be warned! I tried that and lost key folders that are unable to be restored... Ouch! — Gabe Karkanis, Oct 27 '16 at 21:01
hitting `git status` gives a suggestion on how to do that! `git checkout -- .` — Paulo, Dec 21 '17 at 10:42
git gui has a feature which will safely revert changes. .gitignore is honored by this program where as git-clean doesn't use it at all. — wheredidthatnamecomefrom, Jan 13 '18 at 15:24
@Readonly I think, the question should be, "How do I discard unstaged changes in Working Tree" Because you can unstage changes in staging area by `git reset HEAD file1` that overwrites `file1` from most recent commit in commit History.to Staging area. — overexchange, Jan 17 '19 at 20:33
@Paulo: starting in July 2019, `git status` gives the suggestion: `git restore`. `git restore` is a new command exactly for this purpose. See [my 2019 update](https://stackoverflow.com/a/57880896/9210961). — prosoitos, Sep 12 '19 at 20:39
I think either the question or the title should be changed. The title is not the same as the question asked, it is not clear whether the answers cover both. — Josh C, Oct 14 '19 at 04:40

score 5900 · Answer 1 · edited Dec 23 '20 at 16:24

5900

For all unstaged files in current working directory use:

git checkout -- .

For a specific file use:

git checkout -- path/to/file/to/revert

-- here to remove argument disambiguation.

For Git 2.23 onwards, one may want to use the more specific

git restore .

resp.

git restore path/to/file/to/revert

that together with git switch replaces the overloaded git checkout (see here), and thus removes the argument disambiguation.

edited Dec 23 '20 at 16:24

Carsten Führmann

2,102
3
23
20

answered Sep 09 '08 at 19:37

Tobi

65,270
5
29
36

125

This seems to be the git canonical way. i.e. exactly what git tells you to do if you type `git status` – ABMagil Aug 18 '14 at 16:01
31

Doesn't work if there are untracked files. Git says `error: The following untracked working tree files would be overwritten by checkout: ...`. – Michael Iles Aug 24 '14 at 13:26
104

newbie question, what does "git checkout -- ." mean semantically? – kaid Sep 07 '14 at 19:21
1

Michael: start with git clean -df to remove all untracked files first, as suggested in Mariusz' answer above. – Godsmith Sep 26 '14 at 05:27
126

@Ninjack `git checkout -- .` means the same thing as `git checkout .`, except that you're explicit about the fact that you're not specifying the branch name. They both say checkout the HEAD version on the branch I am currently on for '.' or './'. If you do `git checkout branch-name directory-or-file-name` in general, you get the HEAD version of `directory-or-file-name` on branch `branch-name`. – akgill Oct 29 '14 at 19:55
3

`git checkout .` is shorter – Marc-André Lafortune Nov 06 '14 at 20:01
1

IMO this suggestion doesn't handle deletes while stash variant does. – Martin Dvorak Nov 24 '14 at 12:29
"git checkout path/to/file/to/revert" what I have to add if I am on branch, and want contents of file to be replaced by last revision of that file on branch. – Alexey Tigarev Dec 17 '14 at 16:13
26

IMO this variant is imperfect, as it doesn't handle situation when your changed repository is not on the HEAD revision at the moment of changes cleaning and you DO NOT want to update it to HEAD, and want to just clean the changes. – alexykot Jan 05 '15 at 17:27
4

@alexykot "update to HEAD" means cleaning the changes. HEAD is the revision that is currently checked out. – Xandaros Mar 31 '15 at 12:41
yes, indeed, my bad. However `git checkout HEAD` does not actually discard the changes for me, so `stash` based solution is still preferred. – alexykot Apr 01 '15 at 13:10
7

@alexykot: you have to specify a path with `git checkout` otherwise it will not kill changes you made! The trick with `.` is that a checkout with path also includes all subdirectories. – Robert Siemer Apr 19 '15 at 13:46
I do this and get warnings about unmerged files. How do I discard these unmerged files? – Erel Segal-Halevi May 19 '15 at 04:46
3

This will only discard changes to existing files. It will not discard any new files that you have added since the last commit. – AndroidDev Jun 07 '15 at 14:33
1

Interesting. For some reason, this doesn't actually work in a submodule. This has just been driving me nuts! I was CERTAIN that `git clean -- .` should do what I wanted it to do. Reading this answer and testing it confirmed it. But for some reason, IT DOESN'T WORK IN SUBMODULES! Why not? – Ted Middleton Jul 13 '15 at 21:37
1

I prefer the `git stash save --keep-index` solution, because it creates a commit. Even if I do a `git stash drop` immediately after the `stash save` the commit can still be restored. So the `git stash save ...` solution is safer just in case you discarded too much. E.g. using http://stackoverflow.com/questions/89332/recover-dropped-stash-in-git – René Link Jul 17 '15 at 10:41
5

Although it seems obvious, I think it's worth noting that this command should be run from the repository's top-level directory, as it cleans only the current working directory. – Michał Trybus Aug 19 '15 at 12:35
1

Here's a scenario where "git checkout -- ." worked well: I had transferred a repo from Cygwin to Linux via a FAT-formatted USB drive. After transferring the data to Linux, "git status" and "git diff" showed signs of many file permission changes. There were also some other files present (notes and stuff). I used "git checkout -- ." to undo the file permission changes. Now git diff is clean and git status only shows the few files that have been added. The "clean" step from the other answer would be useful if I wanted to get rid of the untracked files. – cardiff space man Sep 15 '15 at 18:53
1

Is it always better using a double dash `git checkout -- path/to/file/to/revert`? – Frozen Flame Dec 10 '15 at 02:19
4

@MichałTrybus to clean the whole repository regardless of where you are inside it, you can use `git checkout -- :/` (I was looking for this myself!) – waldyrious Apr 04 '16 at 15:20
3

I am very confused, this (git checkout -- .) just does *not* work. I still have all my changes (unstaged) files. – PandaWood May 24 '16 at 06:24
That's strange PandaWood. I just used this solution and it did exactly what I wanted. – Wylliam Judd Jul 22 '16 at 21:58
Suppose I made changes in file A (state1), and the file has been modified at Master (state2). If I do git checkout A, to which state will it point now, the previous state1, or updated state2..?? – Bhavuk Mathur Oct 18 '16 at 09:08
Based on information elsewhere and personal experiment, git checkout -- . only considers overwriting files if a corresponding file already exists in the index. @MichaelIles It appears to me that the files causing you trouble must have had checked-in versions elsewhere. – Cris P Feb 27 '18 at 19:54
This removes all the uncommitted changes. If I want to remove only changes made after `git add `? – Khaino Feb 27 '19 at 03:21
4

@ABMagil: there is now a new command: `git restore` and it is the one now given by `git status`. See my [2019 update](https://stackoverflow.com/a/57880896/9210961) – prosoitos Sep 11 '19 at 01:38
To revert an entire sub folder, this works well for me `git checkout -f -- path/to/revert/ ` whereas this does NOT work `git checkout -f -- path/to/revert/*` as any new files git doesn't have a record of. – Shane May 20 '20 at 16:56

score 2944 · Accepted Answer · edited Sep 11 '18 at 00:14

2944

Another quicker way is:

git stash save --keep-index --include-untracked

You don't need to include --include-untracked if you don't want to be thorough about it.

After that, you can drop that stash with a git stash drop command if you like.

edited Sep 11 '18 at 00:14

Brandon Minnick

11,396
12
55
108

answered Sep 09 '08 at 19:39

Greg Hewgill

828,234
170
1,097
1,237

126

And to be thorough about it, you'd want `--include-untracked` as well. – T.J. Crowder Mar 23 '15 at 07:45
I think it is better to use git reset --hard if you don't want to keep track of changes – Karim Samir Apr 12 '15 at 17:25
10

@KarimSamir: The question specifically asks about changes that are *not in the index*. The `git reset` command will discard changes in the index too. – Greg Hewgill Apr 12 '15 at 17:28
159

git checkout -- . is much faster – Frank Apr 17 '15 at 16:16
41

Neither the `git stash`, nor any variety of `git checkout` will discard unstaged deletes. According to the output of `git status`, the actual correct answer here is some flavor `git reset HEAD` – Chris Warth May 27 '15 at 22:27
142

This pollutes the stash stack. `git checkout -- .` does the job with one command only. – Felipe Tonello Sep 09 '15 at 11:17
3

@FelipeTonello I wish I could give you 100 rep for that comment. In my test, that seemed to do exactly what I wanted. Instead, I spent the last hour using "git checkout -- *" and working around all the untracked file errors. – Buttle Butkus Dec 11 '15 at 03:36
@T.J.Crowder How in the world does Git know how to revert an untracked file? Does it just delete it? – Nathan Arthur Apr 05 '16 at 18:44
1

@NathanArthur: Right. Git puts the untracked file in the stash, and then deletes it from the working tree. Restoring the stash copies the untracked file into the working tree, so it shows up as a new untracked file again. – T.J. Crowder Apr 06 '16 at 07:02
@ChrisWarth - git checkout -- does not work for me. Git status still shows untracked changes. – HelloWorldNoMore May 09 '16 at 18:46
How can we the same using Source Tree.? – Mohammad Fareed Jun 14 '16 at 10:58
1

git checkout -- file – sunlover3 Jun 30 '16 at 11:56
1

In the same spirit of this answer, if you do not want to pollute the stash you can just create a new branch, switch back to the original branch, reset, then delete the newly created branch. – Jonn Aug 12 '16 at 08:13
1

You can create an alias for `stash save --keep-index --include-untracked` and use the stash as a recycle bin so you can always easily restore your changes if cleaning them up was a mistake. – Wojtek Owczarczyk Sep 07 '16 at 12:57
@T.J.Crowder "Warning, doing this will permanently delete your files if you have any directory/* entries in your gitignore file." See this post: https://stackoverflow.com/questions/835501/how-do-you-stash-an-untracked-file – ADJenks Jun 30 '17 at 16:37
I lost a bunch of stuff doing that once. Stashing untracked. – ADJenks Jun 30 '17 at 16:37
`git clean` has a dry-run option, `-n` – Justin Reeves Jun 06 '18 at 16:25
`save` option is deprecated in favour of `git stash push`. It differs from "stash push" in that it cannot take pathspecs, and any non-option arguments form the message. [git-scm.com](https://git-scm.com/docs/git-stash) – negas Mar 13 '19 at 16:21
@WojtekOwczarczyk So after using `stash save --keep-index --include-untracked`: How would you restore the changes if you realise that cleaning up was a mistake? – Max Apr 11 '19 at 12:50
`git stash save && git stash drop` is unusable as a general scripting solution, since it will not work (or do nasty things) if there's nothing to stash (and may drop a stash you may have wanted to keep). `git checkout-index -afq && git clean -fdqx` is the real deal! – jlh Jan 22 '21 at 15:06
This worked best for me since I can get my changes back if needed. – Hritik Mar 19 '21 at 11:01

score 2040 · Answer 3 · edited Mar 29 '17 at 02:32

2040

It seems like the complete solution is:

git clean -df
git checkout -- .

git clean removes all untracked files (warning: while it won't delete ignored files mentioned directly in .gitignore, it may delete ignored files residing in folders) and git checkout clears all unstaged changes.

edited Mar 29 '17 at 02:32

Honest Abe

7,434
4
45
59

answered Aug 29 '12 at 18:28

Mariusz Nowak

28,556
4
32
37

131

The other two answers don't actually work, this one did. – John Hunt Sep 01 '14 at 12:23
2

this reverted to previous commit for some reason – dval Oct 01 '14 at 18:03
19

@dval this is becues the first command removed the unindexed files and the second one removed the unstaged changes (of indexed files). So if you did not have any staged changes this it is the same as reverting to the last commit with `git reset --hard` – Amanuel Nega Oct 31 '14 at 10:47
3

use **-dff** if the untracked directory is a git clone. – accuya Dec 16 '14 at 02:52
1

How to understand this command? `-- .`? Does it say checkout current last commit to current folder? – Evan Hu Jan 18 '15 at 05:09
90

Be careful running git clean -df. If you don't understand what it does, you might be deleting files you mean to keep, like robots.txt, uploaded files, etc. – ctlockey Jan 28 '15 at 14:57
43

As @ctlockey said, the first command also **delete directories if they are composed of ignored files only**... Lost a whole bunch of configuration files on my project :( Be careful. – Maxime Lorant Jul 16 '15 at 08:00
This is actually the correct answer. stash and checkout only applies for staged changes. git clean will do – Junchao Gu Oct 01 '15 at 06:21
1

@ctlockey if those are in your repository then you have bigger problems. – rightfold Dec 28 '15 at 12:31
The 2 answers above don't work for unstaged changes.Only this one . – Michael IV May 16 '16 at 15:56
I suspect this works where the others don't perhaps because in my case I deleted not just files but also folders. – Goose Jun 13 '16 at 14:45
3

Erorgh!!! Did I just delete my project folders with git clean -df? How do i get this back? Please help!!!! I dod a ls and I cannot see another folder that I had no intention to delete – user2441441 Jul 29 '16 at 17:17
2

@user2441441: you're out of luck: you've cleaned files that were not under version control. Important files should _always_ be under version control (not necessarily as part of the repository they're located in: you can put them in another, private repository and symlink to them). And files that are in a repo's working directory but not in the version controlled by that repo should always be [`.gitignore`d](http://stackoverflow.com/documentation/git/245/ignoring-files-and-folders). – leftaroundabout Sep 16 '16 at 11:32
i've been using these commands for years. have a case now where none of them works. it just keeps saying "changes not staged for commit" and listing the same files. there are no errors when i do clean or checkout! – Sonic Soul Nov 29 '16 at 19:07
You have to be at the root of your git repository for this to work correctly. – bejado Jun 03 '17 at 00:06
1

Downvoted as it might remove your files. Not reliable solution. – Footniko Mar 02 '18 at 14:13
To understand and get used to how `git -df` works, I recommend adding the `n` option if you are still new to running the command, i.e. `git -dfn`. This will run it in `dry-run` mode so you can see what will get deleted without it actually deleting and doing anything. If you are okay with the result, you would run it again without the `n` option. – Dan Mar 11 '19 at 10:34
1

@Footniko, deleting untracked files may be part of the desired behavior, depending on what Readonly meant by "changes". – Keith Russell Jun 03 '19 at 18:39
sometime we need to keep test files so this solution is dangerous, we don't want to stash at all to keep stash and just need us to avoid stash command to pull the data. – wui Feb 13 '20 at 12:57
A good explantation of `git clean`, options and usage: https://www.atlassian.com/git/tutorials/undoing-changes/git-clean – Ambareesh Sep 07 '20 at 21:07
One of my favorite answers on SO that I come back to. As with what some commenters mentioned above, everything has a time and place. My best use case for this is that I have just pushed a working version to the remote and now I started working on something which should not see the light of day and I just want to get back to the previous version and do not mind all the changes being (files/directories) being deleted. – Shawn Frank Mar 06 '21 at 03:35
This answer was a key part of my answer to [Why git can't do hard/soft resets by path? / How to do git `--hard`/`--soft` resets by path](https://stackoverflow.com/a/66539777/4561887). – Gabriel Staples Mar 09 '21 at 20:21
Update: `git clean -df` and `git checkout-index -fa` is much better. I think `git checkout-index -fa` produces a more-desirable result than `git checkout -- .`. I've added these commands, with thorough explanations, to my answer here: [Using git, how do you reset the working tree (local file system state) to the state of the index (“staged” files)?](https://stackoverflow.com/a/66589020/4561887). – Gabriel Staples Mar 11 '21 at 19:57

score 349 · Answer 4 · answered Jun 20 '09 at 10:28

349

This checks out the current index for the current directory, throwing away all changes in files from the current directory downwards.

git checkout .

or this which checks out all files from the index, overwriting working tree files.

git checkout-index -a -f

answered Jun 20 '09 at 10:28

CB Bailey

648,528
94
608
638

16

+1 This is the RIGHT ANSWER, as it correctly handles the case where some files have both staged **and** un-staged changes. Note that this solution DISCARDS the unstaged changes; if you wish to retain them, then you should use @greg-hewgill 's answer of `git stash save --keep-index`. – Rhubbarb Jun 15 '15 at 15:12
`git checkout --` does not work if you have only one branch. `git checkout .` always works. – Ed Bayiates Jun 29 '18 at 16:23
Thank you so much! Finally an answer that ALWAYS works! This may be combined with `git clean` to also remove untracked files. – jlh Jan 22 '21 at 15:02

score 264 · Answer 5 · edited May 15 '15 at 13:42

264

git clean -df

Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.

-d: Remove untracked directories in addition to untracked files

-f: Force (might be not necessary depending on clean.requireForce setting)

Run git help clean to see the manual

edited May 15 '15 at 13:42

falsarella

11,640
8
65
104

answered Dec 07 '11 at 13:09

Elvis Ciotti

4,348
1
21
17

why this answer doesn't have all the votes? answered back in the 2011 and still correct. – Eugene Braginets Mar 01 '18 at 13:20

prosoitos · Answer 6 · 2021-04-03T16:47:32.450

130

2019 update

You can now discard unstaged changes in one tracked file with:

git restore <file>

and in all tracked files in the current directory (recursively) with:

git restore .

If you run the latter from the root of the repository, it will discard unstaged changes in all tracked files in the project.

Notes

git restore was introduced in July 2019 and released in version 2.23 as part of a split of the git checkout command into git restore for files and git switch for branches.
git checkout still behaves as it used to and the older answers remain perfectly valid.
When running git status with unstaged changes in the working tree, this is now what Git suggests to use to discard them (instead of git checkout -- <file> as it used to prior to v2.23).
As with git checkout -- ., this only discards changes in tracked files. So Mariusz Nowak's answer still applies and if you want to discard all unstaged changes, including untracked files, you could run, as he suggests, an additional git clean -df.

edited Apr 03 '21 at 16:47

answered Sep 11 '19 at 01:30

prosoitos

4,676
5
19
35

3

I wanted to revert my unstaged changes only without affecting newly added files so a `git restore .` worked perfectly. Thanks. – Saurabh Misra Dec 02 '19 at 10:23
4

I did `git restore ` and it worked perfectly. – Merlin Jan 14 '20 at 19:13
1

Worked fine for me. – Hashim Aziz Mar 12 '20 at 00:18
1

According to the man page `git restore .` restores all files in current directory, not in the whole repository. – jarno May 22 '20 at 12:48
2

You are right. Thanks! I just tested it and indeed, that is the case. It is, however, recursive. So when run from the root of the project, it applies to the whole repository. I will edit my answer. – prosoitos May 22 '20 at 19:57
1

@bob 2.23 https://github.com/git/git/blob/master/Documentation/RelNotes/2.23.0.txt – jarno Jun 08 '20 at 23:13
Thanks @Tycholiz. At the time the question was asked and the answer accepted, this new command did not exist :) So it makes a lot of sense that it is not the accepted answer :) – prosoitos Sep 20 '20 at 19:54
1

Should be the accepted answer in 2020! – Colin McDonnell Dec 13 '20 at 17:41
1

Thank you! That's a life-changer. I was previously doing `git commit -m "wip" && git reset --hard && git reset --soft HEAD~1 && git reset`. – Alexandre Gomes Feb 12 '21 at 09:57

Ben · Answer 7 · 2015-02-23T19:46:03.130

117

My favorite is

git checkout -p

That lets you selectively revert chunks.

See also:

git add -p

edited Feb 23 '15 at 19:46

answered Oct 10 '14 at 12:31

Ben

6,598
1
34
41

11

I love the ability to see the actual change before it's discarded. – Penghe Geng Feb 03 '15 at 21:42
This is what I use. git checkout -p and then "a" to accept all. – Mattis Apr 24 '15 at 06:51
3

I've never thought about. That `-p` adds a nice extra layer of safety. Combine it with `git clean -d` to actually answer OP. – Stephan Henningsen Apr 27 '16 at 06:39

score 110 · Answer 8 · edited Jul 14 '20 at 21:07

110

Since no answer suggests the exact option combination that I use, here it is:

git clean -dxn .  # dry-run to inspect the list of files-to-be-removed
git clean -dxf .  # REMOVE ignored/untracked files (in the current directory)
git checkout -- . # ERASE changes in tracked files (in the current directory)

This is the online help text for the used git clean options:

-d

Remove untracked directories in addition to untracked files. If an untracked directory is managed by a different Git repository, it is not removed by default. Use -f option twice if you really want to remove such a directory.

-x

Don’t use the standard ignore rules read from .gitignore (per directory) and $GIT_DIR/info/exclude, but do still use the ignore rules given with -e options. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git reset) to create a pristine working directory to test a clean build.

-n

Don’t actually remove anything, just show what would be done.

-f

If the Git configuration variable clean.requireForce is not set to false, Git clean will refuse to delete files or directories unless given -f, -n, or -i. Git will refuse to delete directories within the .git subdirectory or file, unless a second -f is given.

edited Jul 14 '20 at 21:07

ErikMD

7,337
1
13
39

answered Apr 28 '16 at 19:46

Martin G

14,280
9
69
82

+1 for this solution. Regarding your remark that "git checkout . needs to be done in the root of the repo", maybe you might mention we can just do `git reset --hard` instead? (which is actually equivalent to `git reset --hard HEAD` and should work whichever is the current directory...) – ErikMD Jan 15 '18 at 20:19
2

Also regarding the first command `git clean -dfx`, here is a tip I use to be on the safe side before running it: just run `git clean -d -x -n` before, to display the list of files-to-be-removed, then confirm the operation by running `git clean -d -x -f` (I put the argument `-n`, resp. `-f` in the end to be able to quickly change it in a terminal) – ErikMD Jan 15 '18 at 20:33
5

Quick note that this is unreversable, and if you have files in `.gitignore` you will lose them. So consider backing up your project before this. – Rob Apr 03 '18 at 03:47
@MartinG I just took the opportunity to incorporate my [two](https://stackoverflow.com/questions/52704/how-do-i-discard-unstaged-changes-in-git/36924148#comment83523686_36924148) [suggestions](https://stackoverflow.com/questions/52704/how-do-i-discard-unstaged-changes-in-git/36924148#comment83524035_36924148), including the one that adds a "dry-run" step (as better safe than sorry!). Anyway, feel free to amend my edit if need be! – ErikMD Jun 25 '20 at 23:07

score 73 · Answer 9 · answered Mar 18 '18 at 00:19

If you merely wish to remove changes to existing files, use checkout (documented here).

git checkout -- .

No branch is specified, so it checks out the current branch.
The double-hyphen (--) tells Git that what follows should be taken as its second argument (path), that you skipped specification of a branch.
The period (.) indicates all paths.

If you want to remove files added since your last commit, use clean (documented here):

git clean -i

The -i option initiates an interactive clean, to prevent mistaken deletions.
A handful of other options are available for a quicker execution; see the documentation.

If you wish to move changes to a holding space for later access, use stash (documented here):

git stash

All changes will be moved to Git's Stash, for possible later access.
A handful of options are available for more nuanced stashing; see the documentation.

This will exactly convert your changes and discard newly added files from previous commit. — Yohan Chung, Feb 21 '19 at 01:07
will it remove the newly added files? or just undo the changes in the old unstaged files? — KawaiKx, Nov 09 '20 at 04:45

score 63 · Answer 10 · edited May 13 '13 at 05:41

I really found this article helpful for explaining when to use what command: http://www.szakmeister.net/blog/2011/oct/12/reverting-changes-git/

There are a couple different cases:

If you haven't staged the file, then you use git checkout. Checkout "updates files in the working tree to match the version in the index". If the files have not been staged (aka added to the index)... this command will essentially revert the files to what your last commit was.

git checkout -- foo.txt
If you have staged the file, then use git reset. Reset changes the index to match a commit.

git reset -- foo.txt

I suspect that using git stash is a popular choice since it's a little less dangerous. You can always go back to it if you accidently blow too much away when using git reset. Reset is recursive by default.

Take a look at the article above for further advice.

A H M Forhadul Islam · Answer 11 · 2017-10-23T09:30:10.237

63

The easiest way to do this is by using this command:

This command is used to discard changes in working directory -

git checkout -- .

https://git-scm.com/docs/git-checkout

In git command, stashing of untracked files is achieved by using:

git stash -u

http://git-scm.com/docs/git-stash

edited Oct 23 '17 at 09:30

answered Apr 12 '17 at 09:27

A H M Forhadul Islam

1,242
11
11

21

Twice I've come here, read this answer, and forgotten the `.` at the end. To future me: the period is *essential*! – bejado Jun 16 '17 at 17:13
3

I needed to get rid of all local changes in a sub directory, without blowing away every other change. This answer helped a lot, thanks – Ally Sep 07 '17 at 04:00
2

Please describe what the two commands do. It's really unhelpful to have no explanation. – Chris Kennedy Sep 09 '17 at 17:22
2

excellent. the checkout does in one command what the most popular one does in two. can also be followed up with `git clean -fd` to clean files not in the index. – oligofren Nov 28 '17 at 09:03

score 50 · Answer 12 · answered Jul 28 '11 at 05:27

50

If you aren't interested in keeping the unstaged changes (especially if the staged changes are new files), I found this handy:

git diff | git apply --reverse

answered Jul 28 '11 at 05:27

Joshua Kunzmann

910
8
10

score 45 · Answer 13 · edited Jan 07 '17 at 01:28

45

As you type git status, (use "git checkout -- ..." to discard changes in working directory) is shown.

e.g. git checkout -- .

edited Jan 07 '17 at 01:28

Dorian

19,009
8
108
111

answered May 17 '16 at 11:27

Erdem ÖZDEMİR

755
7
6

1

Downvoted because it doesn't help to quickly discard all files. The three dots indicate that you are required to list all the files. This is especially bad if you need to discard tons of files at once, eg. during a large merge after you have staged all the modifications you like to keep – usr-local-ΕΨΗΕΛΩΝ Jun 09 '16 at 15:26
3

Of course, the correct command is "git checkout -- ." a single dot. In the comment, the three dots were a grammatical thing, to indicate there are many other options that could have been used.. – Josef.B Sep 20 '16 at 11:01

score 44 · Answer 14 · answered May 17 '14 at 02:28

44

git checkout -f

man git-checkout:

-f, --force

When switching branches, proceed even if the index or the working tree differs from HEAD. This is used to throw away local changes.

When checking out paths from the index, do not fail upon unmerged entries; instead, unmerged entries are ignored.

answered May 17 '14 at 02:28

Bijan

6,157
6
30
27

3

This would discard changes in the index!! (And the OP requires to leave them as is.) – Robert Siemer Apr 19 '15 at 13:59

Asped · Answer 15 · 2015-10-21T08:37:52.870

You can use git stash - if something goes wrong, you can still revert from the stash. Similar to some other answer here, but this one also removes all unstaged files and also all unstaged deletes:

git add .
git stash

if you check that everything is OK, throw the stash away:

git stash drop

The answer from Bilal Maqsood with git clean also worked for me, but with the stash I have more control - if I do sth accidentally, I can still get my changes back

UPDATE

I think there is 1 more change (don't know why this worked for me before):

git add . -A instead of git add .

without the -A the removed files will not be staged

Nick · Answer 16 · 2016-01-21T18:04:56.937

37

Instead of discarding changes, I reset my remote to the origin. Note - this method is to completely restore your folder to that of the repo.

So I do this to make sure they don't sit there when I git reset (later - excludes gitignores on the Origin/branchname)

NOTE: If you want to keep files not yet tracked, but not in GITIGNORE you may wish to skip this step, as it will Wipe these untracked files not found on your remote repository (thanks @XtrmJosh).

git add --all

Then I

git fetch --all

Then I reset to origin

git reset --hard origin/branchname

That will put it back to square one. Just like RE-Cloning the branch, WHILE keeping all my gitignored files locally and in place.

Updated per user comment below: Variation to reset the to whatever current branch the user is on.

git reset --hard @{u}

edited Jan 21 '16 at 18:04

answered Aug 07 '15 at 21:15

Nick

1,121
10
21

This is my preferred option, but why do you add all changes first? So far as I'm aware this just modifies the directory listing in Git files, while using git reset --hard, this will be lost anyway while the directories will still be removed. – XtrmJosh Sep 30 '15 at 10:00
I dont on mac or linux, github windows powershell sometimes leaves the files there after reset. I think its because git reset sets all files in the repo to its original state. If theyre not added, theyre not touched. The desktop client then will pickup the "hey this file is in here and needs to be committed" – Nick Oct 01 '15 at 17:04
Sense made. I don't use Windows so haven't seen that issue (haven't used Windows for the last few months at least, don't remember much before that - it's one huge regrettable blur). Might be worth noting the rationale in your main answer :) – XtrmJosh Oct 02 '15 at 12:18
I ran across this issue on a Mac too now. If the file is not tracked in the Repo sometimes git reset doesnt touch it. I cant really isolate the "WHY" but when that happens, if I reset, and i still have 1 uncommitted file or two, i add --all and reset --hard again – Nick Nov 19 '15 at 02:18
If you haven't committed or staged a new file git completely ignores it and won't touch it. It doesn't want to accidentally delete something you might want. You can see [here](https://git-scm.com/docs/git-status) at `--untracked-files[=]` that untracked files are shown by default in `git status`, and you can tell it not to show them if it bothers you! For the record, `git add --all` will stage the files ready for commit, at which point git recognises them (hence git reset --hard will then work). `git clean` removes untracked files [see here](https://www.git-scm.com/docs/git-clean/1.7.5) – XtrmJosh Nov 19 '15 at 17:41
Thanks - So basically if you git add --all, you can reset, or you have to git add --all , then get clean Guess clean is a few less characters ;) – Nick Nov 21 '15 at 05:38
Pretty much, although if there are untracked files lingering I tend to just leave them alone. Paranoia and all that, makes me think I'll break something :D – XtrmJosh Nov 22 '15 at 09:25
3

A nice little variation of this I like is `git reset --hard @{u}` which resets the branch to wherever the current remote-tracking branch is – user2221343 Jan 06 '16 at 19:39

score 32 · Answer 17 · answered Oct 14 '11 at 21:07

32

Tried all the solutions above but still couldn't get rid of new, unstaged files.

Use git clean -f to remove those new files - with caution though! Note the force option.

answered Oct 14 '11 at 21:07

artur

840
1
9
14

score 28 · Answer 18 · edited Sep 19 '19 at 20:42

28

To do a permanent discard: git reset --hard

To save changes for later: git stash

edited Sep 19 '19 at 20:42

siddhantsomani

824
11
12

answered Jul 03 '19 at 12:41

SANGEETHA P.H.

729
7
7

score 22 · Answer 19 · answered Sep 08 '16 at 06:19

22

Just use:

git stash -u

Done. Easy.

If you really care about your stash stack then you can follow with git stash drop. But at that point you're better off using (from Mariusz Nowak):

git checkout -- .
git clean -df

Nonetheless, I like git stash -u the best because it "discards" all tracked and untracked changes in just one command. Yet git checkout -- . only discards tracked changes, and git clean -df only discards untracked changes... and typing both commands is far too much work :)

answered Sep 08 '16 at 06:19

Ben Wilde

4,984
2
35
34

Note: `git stash -u` will soon (Git 2.14.x/2.15, Q3 2017) evolve a bit: https://stackoverflow.com/a/46027357/6309 – VonC Sep 03 '17 at 20:10
If i get the question of the OP correct the indexed files should be kept. Only unstage changes should be removed. So is should be `git stash -k` in my opinion. – snap Feb 01 '18 at 08:19

score 21 · Answer 20 · edited Jun 30 '15 at 22:12

21

simply say

git stash

It will remove all your local changes. You also can use later by saying

git stash apply

or git stash pop

edited Jun 30 '15 at 22:12

DrB

175
1
2
14

answered Apr 24 '15 at 12:19

piyushmandovra

3,673
2
17
29

score 18 · Answer 21 · answered Aug 27 '19 at 07:58

18

you have a very simple git command git checkout .

answered Aug 27 '19 at 07:58

Khem Raj Regmi

1,454
14
16

GlassGhost · Answer 22 · 2015-09-28T13:29:45.117

16

This works even in directories that are; outside of normal git permissions.

sudo chmod -R 664 ./* && git checkout -- . && git clean -dfx

Happened to me recently

edited Sep 28 '15 at 13:29

answered Sep 05 '13 at 09:38

GlassGhost

13,372
5
26
42

Beware though, that the git ignored content will not retain it's original permissions! Hence it can cause a security risk. – twicejr Dec 10 '14 at 18:06
@twicejr You're wrong, please read `git help clean` "-d Remove untracked directories in addition to untracked files." – GlassGhost Dec 10 '14 at 22:40
Why did you set all your files to be world read/write? Not good practice. – Ghoti Sep 28 '15 at 11:31
@Ghoti my bad, 664 is correct? you're also welcome to edit the answer. – GlassGhost Sep 28 '15 at 13:29
Setting all permissions to 664 makes a lot of assumptions about what kind of permissions the project needs. I think using that part of the command will cause issues for some people. – ianrandmckenzie Nov 20 '18 at 17:12

vivekporwal04 · Answer 23 · 2014-05-31T10:04:10.353

14

cd path_to_project_folder  # take you to your project folder/working directory 
git checkout .             # removes all unstaged changes in working directory

edited May 31 '14 at 10:04

answered May 30 '14 at 09:26

vivekporwal04

405
3
15

score 14 · Answer 24 · edited Jan 29 '18 at 16:29

14

No matter what state your repo is in you can always reset to any previous commit:

git reset --hard <commit hash>

This will discard all changes which were made after that commit.

edited Jan 29 '18 at 16:29

jdgregson

1,212
14
27

answered Feb 05 '16 at 00:59

msangel

8,829
3
43
64

3

This will also discard everything in the index (not just things not in the index), which is beyond what the OP is asking for. – Linus Arver Jul 08 '18 at 07:51

score 12 · Answer 25 · answered Jul 14 '16 at 07:03

In my opinion,

git clean -df

should do the trick. As per Git documentation on git clean

git-clean - Remove untracked files from the working tree

Description

Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.

Normally, only files unknown to Git are removed, but if the -x option is specified, ignored files are also removed. This can, for example, be useful to remove all build products.

If any optional ... arguments are given, only those paths are affected.

Options

-d Remove untracked directories in addition to untracked files. If an untracked directory is managed by a different Git repository, it is not removed by default. Use -f option twice if you really want to remove such a directory.

-f --force If the Git configuration variable clean.requireForce is not set to false, git clean will refuse to run unless given -f, -n or -i.

score 10 · Answer 26 · answered Jun 15 '12 at 08:55

Another way to get rid of new files that is more specific than git clean -df (it will allow you to get rid of some files not necessarily all), is to add the new files to the index first, then stash, then drop the stash.

This technique is useful when, for some reason, you can't easily delete all of the untracked files by some ordinary mechanism (like rm).

bbarker · Answer 27 · 2014-01-13T16:42:46.727

What follows is really only a solution if you are working with a fork of a repository where you regularly synchronize (e.g. pull request) with another repo. Short answer: delete fork and refork, but read the warnings on github.

I had a similar problem, perhaps not identical, and I'm sad to say my solution is not ideal, but it is ultimately effective.

I would often have git status messages like this (involving at least 2/4 files):

$ git status
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   doc/PROJECT/MEDIUM/ATS-constraint/constraint_s2var.dats
#       modified:   doc/PROJECT/MEDIUM/ATS-constraint/parsing/parsing_s2var.dats
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   doc/PROJECT/MEDIUM/ATS-constraint/constraint_s2Var.dats
#       modified:   doc/PROJECT/MEDIUM/ATS-constraint/parsing/parsing_s2Var.dats

A keen eye will note that these files have dopplegangers that are a single letter in case off. Somehow, and I have no idea what led me down this path to start with (as I was not working with these files myself from the upstream repo), I had switched these files. Try the many solutions listed on this page (and other pages) did not seem to help.

I was able to fix the problem by deleting my forked repository and all local repositories, and reforking. This alone was not enough; upstream had to rename the files in question to new filenames. As long as you don't have any uncommited work, no wikis, and no issues that diverge from the upstream repository, you should be just fine. Upstream may not be very happy with you, to say the least. As for my problem, it is undoubtedly a user error as I'm not that proficient with git, but the fact that it is far from easy to fix points to an issue with git as well.

score 9 · Answer 28 · edited Jul 18 '17 at 12:23

9

I had a weird situation where a file is always unstaged, this helps me to resolve.

git rm .gitattributes
git add -A
git reset --hard

edited Jul 18 '17 at 12:23

Vadim Kotov

7,103
8
44
57

answered Feb 08 '17 at 11:58

SDV

233
2
7

twicejr · Answer 29 · 2015-04-20T10:39:40.610

8

When you want to transfer a stash to someone else:

# add files
git add .  
# diff all the changes to a file
git diff --staged > ~/mijn-fix.diff
# remove local changes 
git reset && git checkout .
# (later you can re-apply the diff:)
git apply ~/mijn-fix.diff

[edit] as commented, it ís possible to name stashes. Well, use this if you want to share your stash ;)

edited Apr 20 '15 at 10:39

answered Jul 08 '13 at 15:07

twicejr

1,249
3
13
21

5

Actually Git stash can have a title. For instance `git stash save "Feature X work in progress"`. – Colin D Bennett Dec 09 '14 at 22:39

Pau · Answer 30 · 2017-06-05T04:51:09.557

You could create your own alias which describes how to do it in a descriptive way.

I use the next alias to discard changes.

Discard changes in a (list of) file(s) in working tree

discard = checkout --

Then you can use it as next to discard all changes:

discard .

Or just a file:

discard filename

Otherwise, if you want to discard all changes and also the untracked files, I use a mix of checkout and clean:

Clean and discard changes and untracked files in working tree

cleanout = !git clean -df && git checkout -- .

So the use is simple as next:

cleanout

Now is available in the next Github repo which contains a lot of aliases:

https://github.com/GitAlias/gitalias

score 7 · Answer 31 · edited Jul 18 '17 at 12:22

7

If you are in case of submodule and no other solutions work try:

To check what is the problem (maybe a "dirty" case) use:

git diff
To remove stash

git submodule update

edited Jul 18 '17 at 12:22

Vadim Kotov

7,103
8
44
57

answered Oct 01 '15 at 21:32

onalbi

2,059
21
34

Ivan · Answer 32 · 2015-09-04T09:56:53.897

If all the staged files were actually committed, then the branch can simply be reset e.g. from your GUI with about three mouse clicks: Branch, Reset, Yes!

So what I often do in practice to revert unwanted local changes is to commit all the good stuff, and then reset the branch.

If the good stuff is committed in a single commit, then you can use "amend last commit" to bring it back to being staged or unstaged if you'd ultimately like to commit it a little differently.

This might not be the technical solution you are looking for to your problem, but I find it a very practical solution. It allows you to discard unstaged changes selectively, resetting the changes you don't like and keeping the ones you do.

So in summary, I simply do commit, branch reset, and amend last commit.

score 6 · Answer 33 · answered Jul 31 '17 at 15:57

If it's almost impossible to rule out modifications of the files, have you considered ignoring them? If this statement is right and you wouldn't touch those files during your development, this command may be useful:

git update-index --assume-unchanged file_to_ignore

score 5 · Answer 34 · answered Nov 23 '15 at 04:30

None of the solutions work if you just changed the permissions of a file (this is on DOS/Windoze)

Mon 23/11/2015-15:16:34.80 C:\...\work\checkout\slf4j+> git status
On branch SLF4J_1.5.3
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

        modified:   .gitignore
        modified:   LICENSE.txt
        modified:   TODO.txt
        modified:   codeStyle.xml
        modified:   pom.xml
        modified:   version.pl

no changes added to commit (use "git add" and/or "git commit -a")

Mon 23/11/2015-15:16:37.87 C:\...\work\checkout\slf4j+> git diff
diff --git a/.gitignore b/.gitignore
old mode 100644
new mode 100755
diff --git a/LICENSE.txt b/LICENSE.txt
old mode 100644
new mode 100755
diff --git a/TODO.txt b/TODO.txt
old mode 100644
new mode 100755
diff --git a/codeStyle.xml b/codeStyle.xml
old mode 100644
new mode 100755
diff --git a/pom.xml b/pom.xml
old mode 100644
new mode 100755
diff --git a/version.pl b/version.pl
old mode 100644
new mode 100755

Mon 23/11/2015-15:16:45.22 C:\...\work\checkout\slf4j+> git reset --hard HEAD
HEAD is now at 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Added .gitignore

Mon 23/11/2015-15:16:47.42 C:\...\work\checkout\slf4j+> git clean -f

Mon 23/11/2015-15:16:53.49 C:\...\work\checkout\slf4j+> git stash save -u
Saved working directory and index state WIP on SLF4J_1.5.3: 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Added .gitignore
HEAD is now at 8fa8488 12133-CHIXMISSINGMESSAGES MALCOLMBOEKHOFF 20141223124940 Added .gitignore

Mon 23/11/2015-15:17:00.40 C:\...\work\checkout\slf4j+> git stash drop
Dropped refs/stash@{0} (cb4966e9b1e9c9d8daa79ab94edc0c1442a294dd)

Mon 23/11/2015-15:17:06.75 C:\...\work\checkout\slf4j+> git stash drop
Dropped refs/stash@{0} (e6c49c470f433ce344e305c5b778e810625d0529)

Mon 23/11/2015-15:17:08.90 C:\...\work\checkout\slf4j+> git stash drop
No stash found.

Mon 23/11/2015-15:17:15.21 C:\...\work\checkout\slf4j+> git checkout -- .

Mon 23/11/2015-15:22:00.68 C:\...\work\checkout\slf4j+> git checkout -f -- .

Mon 23/11/2015-15:22:04.53 C:\...\work\checkout\slf4j+> git status
On branch SLF4J_1.5.3
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

        modified:   .gitignore
        modified:   LICENSE.txt
        modified:   TODO.txt
        modified:   codeStyle.xml
        modified:   pom.xml
        modified:   version.pl

no changes added to commit (use "git add" and/or "git commit -a")

Mon 23/11/2015-15:22:13.06 C:\...\work\checkout\slf4j+> git diff
diff --git a/.gitignore b/.gitignore
old mode 100644
new mode 100755
diff --git a/LICENSE.txt b/LICENSE.txt
old mode 100644
new mode 100755
diff --git a/TODO.txt b/TODO.txt
old mode 100644
new mode 100755
diff --git a/codeStyle.xml b/codeStyle.xml
old mode 100644
new mode 100755
diff --git a/pom.xml b/pom.xml
old mode 100644
new mode 100755
diff --git a/version.pl b/version.pl
old mode 100644
new mode 100755

The only way to fix this is to manually reset the permissions on the changed files:

Mon 23/11/2015-15:25:43.79 C:\...\work\checkout\slf4j+> git status -s | egrep "^ M" | cut -c4- | for /f "usebackq tokens=* delims=" %A in (`more`) do chmod 644 %~A

Mon 23/11/2015-15:25:55.37 C:\...\work\checkout\slf4j+> git status
On branch SLF4J_1.5.3
nothing to commit, working directory clean

Mon 23/11/2015-15:25:59.28 C:\...\work\checkout\slf4j+>

Mon 23/11/2015-15:26:31.12 C:\...\work\checkout\slf4j+> git diff

The Schwartz · Answer 35 · 2020-09-18T06:12:16.410

5

Just as a reminder, newer versions of git has the restore command, which also is a suggestion when typing git status when you have changed files:

(use "git add ..." to update what will be committed)

(use "git restore ..." to discard changes in working directory)

So git 'restore' is the modern solution to this. It is always a good idea to read the suggestions from git after typing 'git status' :-)

edited Sep 18 '20 at 06:12

answered Sep 18 '20 at 06:03

The Schwartz

687
1
7
10

2

This just repeat https://stackoverflow.com/a/57880896/6309. – VonC Sep 18 '20 at 06:17
It sure is, just stating the obvious and that git tries to help with the comments from a 'git status' call :-) – The Schwartz Sep 21 '20 at 08:44

score 1 · Answer 36 · answered Dec 23 '16 at 17:33

Just use:

git stash -k -u

This will stash unstaged changes and untracked files (new files) and keep staged files.

It's better than reset/checkout/clean, because you might want them back later (by git stash pop). Keeping them in the stash is better than discarding them.

How do I discard unstaged changes in Git?

36 Answers36

2019 update

Notes

Discard changes in a (list of) file(s) in working tree

Clean and discard changes and untracked files in working tree

Linked

Related