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 ambiguity (this is known as 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.
git-clean - Remove untracked files from the working tree
Synopsis
git clean [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>…​
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 <path>...
arguments are given, only those paths are affected.
Step 1 is to show what will be deleted by using the -n
option:
# Print out the list of files and directories which will be removed (dry run)
git clean -n -d
Clean Step - beware: this will delete files:
# Delete the files from the repository
git clean -f
- To remove directories, run
git clean -f -d
or git clean -fd
- To remove ignored files, run
git clean -f -X
or git clean -fX
- To remove ignored and non-ignored files, run
git clean -f -x
or git clean -fx
Note the case difference on the X
for the two latter commands.
If clean.requireForce
is set to "true" (the default) in your configuration, one needs to specify -f
otherwise nothing will actually happen.
Again see the git-clean
docs for more information.
Options
-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
.
-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.
-X
Remove only files ignored by Git. This may be useful to rebuild
everything from scratch, but keep manually created files.
-n
, --dry-run
Don’t actually remove anything, just show what would be done.
-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.
Best Answer
🚀 A blazingly fast shell one-liner 🚀
This shell script displays all blob objects in the repository, sorted from smallest to largest.
For my sample repo, it ran about 100 times faster than the other ones found here.
On my trusty Athlon II X4 system, it handles the Linux Kernel repository with its 5.6 million objects in just over a minute.
The Base Script
When you run above code, you will get nice human-readable output like this:
macOS users: Since
numfmt
is not available on macOS, you can either omit the last line and deal with raw byte sizes orbrew install coreutils
.Filtering
To achieve further filtering, insert any of the following lines before the
sort
line.To exclude files that are present in
HEAD
, insert the following line:To show only files exceeding given size (e.g. 1 MiB = 220 B), insert the following line:
Output for Computers
To generate output that's more suitable for further processing by computers, omit the last two lines of the base script. They do all the formatting. This will leave you with something like this:
Appendix
File Removal
For the actual file removal, check out this SO question on the topic.
Understanding the meaning of the displayed file size
What this script displays is the size each file would have in the working directory. If you want to see how much space a file occupies if not checked out, you can use
%(objectsize:disk)
instead of%(objectsize)
. However, mind that this metric also has its caveats, as is mentioned in the documentation.More sophisticated size statistics
Sometimes a list of big files is just not enough to find out what the problem is. You would not spot directories or branches containing humongous numbers of small files, for example.
So if the script here does not cut it for you (and you have a decently recent version of git), look into
git-filter-repo --analyze
orgit rev-list --disk-usage
(examples).