Sign up ×
Stack Overflow is a community of 4.7 million programmers, just like you, helping each other. Join them; it only takes a minute:

This question already has an answer here:

How can I clear my working directory in git?

share|improve this question

marked as duplicate by Marc Audet, Jake N, giammin, J. Costa, Emile Feb 18 '14 at 11:59

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

up vote 609 down vote accepted

To reset a specific file to the last-committed state (to discard uncommitted changes in a specific file):

git checkout thefiletoreset.txt

This is mentioned in the git status output:

(use "git checkout -- <file>..." to discard changes in working directory)

To reset the entire repository to the last committed state:

git reset --hard

To remove untracked files, I usually just delete all files in the working copy (but not the .git/ folder!), then do git reset --hard which leaves it with only committed files.

A better way is to use git clean:

git clean -d -x -f

will remove untracked files, including directories (-d) and files ignored by git (-x). Replace the -f argument with -n to perform a dry-run or -i for interactive mode and it will tell you what will be removed.

Relevant links:

share|improve this answer
10  
Note that by default, 'git clean -d' is insufficient. You need to also add the -f (force) flag. Also, if you want to additionally delete the files that are ignored by .gitignore, then you need to add the -x option. Here's what it all looks like: git clean -xdf – Matt Ball Apr 6 '11 at 15:05
1  
I think you mean "working directory" instead of "repository" in the sentence "I usually just delete all files in the repository". – Dr. Person Person II Jun 7 '11 at 11:45
    
@Dr. Person Good point, that is clearer, edited – dbr Jun 8 '11 at 13:58
7  
However be sure to NOTE that command will also blow away your local sqlite database -- not undo recent changes, but actually delete it. Sp the "-x" option might NOT ne a good idea depending on what you are trying to do. – jpwynn Apr 2 '12 at 0:54
6  
Please note: the suggestion to delete all the files except the .git/ folder and then restore by running git reset --hard will probably take a long time if your repo has been around for any time at all. Please don't do this. Use git clean. – guiniveretoo Sep 12 '13 at 17:34
git clean -df

Edit: It's not well advertised but git clean is really handy. Git Ready has a nice intro to git clean.

Update: removed the x flag based on the suggestion in the comment below

share|improve this answer
17  
I suggest to not use the -x parameter as it will remove all gitignored content. Say you have a folder named 'gitignored' added to .gitignore, and you store there your files that have to be secure, you're also deleting them using -x parameter – Highmastdon Dec 21 '12 at 12:39
    
Oops. git clean -xdf also removed .gitignore, and I did not notice before the next commit. I won't ignore .gitignore anymore. :) – Grastveit Sep 12 '13 at 8:43
1  
@Grastveit git clean -xdf will remove .gitignore if and only if it has not been added to, thus working as intended. – Marko Sep 13 '13 at 6:58
2  
let's highlight this: ๐ˆ ๐ฌ๐ฎ๐ ๐ ๐ž๐ฌ๐ญ ๐ญ๐จ ๐ง๐จ๐ญ ๐ฎ๐ฌ๐ž ๐ญ๐ก๐ž -๐ฑ ๐ฉ๐š๐ซ๐š๐ฆ๐ž๐ญ๐ž๐ซ ๐š๐ฌ ๐ข๐ญ ๐ฐ๐ข๐ฅ๐ฅ ๐ซ๐ž๐ฆ๐จ๐ฏ๐ž ๐š๐ฅ๐ฅ ๐ ๐ข๐ญ๐ข๐ ๐ง๐จ๐ซ๐ž๐ ๐œ๐จ๐ง๐ญ๐ž๐ง๐ญ – mef Nov 19 '14 at 14:40
2  
@Marko sure, everyone is free to use -x or not. But some people may read this github answer, copy-paste the command, and without realizing it loose all their gitignored files they wanted to keep. Then come back here and only notice @Highmastdon's comment, about the consequence of using -x. – mef Dec 3 '14 at 15:01

All the answers so far retain local commits. If you're really serious, you can discard all local commits and all local edits by doing:

git reset --hard origin/branchname

For example:

git reset --hard origin/master

This makes your local repository exactly match the state of the origin (other than untracked files).

If you accidentally did this after just reading the command, and not what it does :), use git reflog to find your old commits.

share|improve this answer

You could create a commit which contains an empty working copy.

This is a generally safe, non-destructive approach because it does not involve the use of any brute-force reset mechanisms. First you hide all managed content with git checkout empty, then you are free to manually review and remove whatever unmanaged content remains.

## create and initialize a temporary repo with an empty working copy
(
mkdir ./temp-repo && cd ./temp-repo && git init
touch ./temp-file && git add . && git commit -m "almost empty"
git rm ./temp-file && git commit -m "empty"
git tag empty
)

## fetch the history from the temporary repo
git remote add empty ./temp-repo && git fetch --tags empty && git remote rm empty
gvfs-trash ./temp-repo ## delete the temporary repo

## clear the working copy
git checkout empty

Your working copy should now be clear of any managed content. All that remains are unmanaged files and the .git folder itself.

To re-populate your working copy...

git checkout master ## or whatever branch you will be using
share|improve this answer
    
This can also be a nice way to save some disk-space in a pinch. – nobar Jan 25 '13 at 5:24
3  
A much faster way to create the empty checkout: true | git mktree | xargs git commit-tree | xargs git tag empty – jthill Mar 21 '13 at 18:15
    
@jthill: That seems to work -- thanks for the tip! – nobar Mar 21 '13 at 23:42
1  
Note: There seems to be some value in using an empty commit as the base for projects. This makes it easier to perform full-project rebase operations in case your initial commit needs to be fixed -- and may simplify things when pushing an existing git repository to svn. – nobar Aug 16 '13 at 15:57
    
Like most other workflows, this gets messy if you are using Git submodules. – nobar May 16 at 2:23

To switch to another branch, discarding all uncommitted changes (e.g. resulting from Git's strange handling of line endings):

git checkout -f <branchname>

I had a working copy with hundreds of changed files (but empty git diff --ignore-space-at-eol) which I couldn't get rid off with any of the commands I read here, and git checkout <branchname> won't work, either - unless given the -f (or --force) option.

share|improve this answer

To reset a specific file as git status suggests:

git checkout <filename>

To reset a folder

git checkout <foldername>/*
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.