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
In general,
git reset
's function is to take the current branch and reset it to point somewhere else, and possibly bring the index and work tree along. More concretely, if your master branch (currently checked out) is like this:and you realize you want master to point to B, not C, you will use
git reset B
to move it there:Digression: This is different from a checkout. If you'd run
git checkout B
, you'd get this:You've ended up in a detached HEAD state.
HEAD
, work tree, index all matchB
, but the master branch was left behind atC
. If you make a new commitD
at this point, you'll get this, which is probably not what you want:Remember, reset doesn't make commits, it just updates a branch (which is a pointer to a commit) to point to a different commit. The rest is just details of what happens to your index and work tree.
Use cases
I cover many of the main use cases for
git reset
within my descriptions of the various options in the next section. It can really be used for a wide variety of things; the common thread is that all of them involve resetting the branch, index, and/or work tree to point to/match a given commit.Things to be careful of
--hard
can cause you to really lose work. It modifies your work tree.git reset [options] commit
can cause you to (sort of) lose commits. In the toy example above, we lost commitC
. It's still in the repo, and you can find it by looking atgit reflog show HEAD
orgit reflog show master
, but it's not actually accessible from any branch anymore.Git permanently deletes such commits after 30 days, but until then you can recover C by pointing a branch at it again (
git checkout C; git branch <new branch name>
).Arguments
Paraphrasing the man page, most common usage is of the form
git reset [<commit>] [paths...]
, which will reset the given paths to their state from the given commit. If the paths aren't provided, the entire tree is reset, and if the commit isn't provided, it's taken to be HEAD (the current commit). This is a common pattern across git commands (e.g. checkout, diff, log, though the exact semantics vary), so it shouldn't be too surprising.For example,
git reset other-branch path/to/foo
resets everything in path/to/foo to its state in other-branch,git reset -- .
resets the current directory to its state in HEAD, and a simplegit reset
resets everything to its state in HEAD.The main work tree and index options
There are four main options to control what happens to your work tree and index during the reset.
Remember, the index is git's "staging area" - it's where things go when you say
git add
in preparation to commit.--hard
makes everything match the commit you've reset to. This is the easiest to understand, probably. All of your local changes get clobbered. One primary use is blowing away your work but not switching commits:git reset --hard
meansgit reset --hard HEAD
, i.e. don't change the branch but get rid of all local changes. The other is simply moving a branch from one place to another, and keeping index/work tree in sync. This is the one that can really make you lose work, because it modifies your work tree. Be very very sure you want to throw away local work before you run anyreset --hard
.--mixed
is the default, i.e.git reset
meansgit reset --mixed
. It resets the index, but not the work tree. This means all your files are intact, but any differences between the original commit and the one you reset to will show up as local modifications (or untracked files) with git status. Use this when you realize you made some bad commits, but you want to keep all the work you've done so you can fix it up and recommit. In order to commit, you'll have to add files to the index again (git add ...
).--soft
doesn't touch the index or work tree. All your files are intact as with--mixed
, but all the changes show up aschanges to be committed
with git status (i.e. checked in in preparation for committing). Use this when you realize you've made some bad commits, but the work's all good - all you need to do is recommit it differently. The index is untouched, so you can commit immediately if you want - the resulting commit will have all the same content as where you were before you reset.--merge
was added recently, and is intended to help you abort a failed merge. This is necessary becausegit merge
will actually let you attempt a merge with a dirty work tree (one with local modifications) as long as those modifications are in files unaffected by the merge.git reset --merge
resets the index (like--mixed
- all changes show up as local modifications), and resets the files affected by the merge, but leaves the others alone. This will hopefully restore everything to how it was before the bad merge. You'll usually use it asgit reset --merge
(meaninggit reset --merge HEAD
) because you only want to reset away the merge, not actually move the branch. (HEAD
hasn't been updated yet, since the merge failed)To be more concrete, suppose you've modified files A and B, and you attempt to merge in a branch which modified files C and D. The merge fails for some reason, and you decide to abort it. You use
git reset --merge
. It brings C and D back to how they were inHEAD
, but leaves your modifications to A and B alone, since they weren't part of the attempted merge.Want to know more?
I do think
man git reset
is really quite good for this - perhaps you do need a bit of a sense of the way git works for them to really sink in though. In particular, if you take the time to carefully read them, those tables detailing states of files in index and work tree for all the various options and cases are very very helpful. (But yes, they're very dense - they're conveying an awful lot of the above information in a very concise form.)Strange notation
The "strange notation" (
HEAD^
andHEAD~1
) you mention is simply a shorthand for specifying commits, without having to use a hash name like3ebe3f6
. It's fully documented in the "specifying revisions" section of the man page for git-rev-parse, with lots of examples and related syntax. The caret and the tilde actually mean different things:HEAD~
is short forHEAD~1
and means the commit's first parent.HEAD~2
means the commit's first parent's first parent. Think ofHEAD~n
as "n commits before HEAD" or "the nth generation ancestor of HEAD".HEAD^
(orHEAD^1
) also means the commit's first parent.HEAD^2
means the commit's second parent. Remember, a normal merge commit has two parents - the first parent is the merged-into commit, and the second parent is the commit that was merged. In general, merges can actually have arbitrarily many parents (octopus merges).^
and~
operators can be strung together, as inHEAD~3^2
, the second parent of the third-generation ancestor ofHEAD
,HEAD^^2
, the second parent of the first parent ofHEAD
, or evenHEAD^^^
, which is equivalent toHEAD~3
.