How do I undo 'git add' before commit?
Solution 1
You can undo git add
before commit with
git reset <file>
which will remove it from the current index (the "about to be committed" list) without changing anything else.
You can use
git reset
without any file name to unstage all due changes. This can come in handy when there are too many files to be listed one by one in a reasonable amount of time.
In old versions of Git, the above commands are equivalent to git reset HEAD <file>
and git reset HEAD
respectively, and will fail if HEAD
is undefined (because you haven't yet made any commits in your repository) or ambiguous (because you created a branch called HEAD
, which is a stupid thing that you shouldn't do). This was changed in Git 1.8.2, though, so in modern versions of Git you can use the commands above even prior to making your first commit:
"git reset" (without options or parameters) used to error out when you do not have any commits in your history, but it now gives you an empty index (to match non-existent commit you are not even on).
Documentation: git reset
Solution 2
You want:
git rm --cached <added_file_to_undo>
Reasoning:
When I was new to this, I first tried
git reset .
(to undo my entire initial add), only to get this (not so) helpful message:
fatal: Failed to resolve 'HEAD' as a valid ref.
It turns out that this is because the HEAD ref (branch?) doesn't exist until after the first commit. That is, you'll run into the same beginner's problem as me if your workflow, like mine, was something like:
- cd to my great new project directory to try out Git, the new hotness
git init
git add .
-
git status
... lots of crap scrolls by ...
=> Damn, I didn't want to add all of that.
-
google "undo git add"
=> find Stack Overflow - yay
-
git reset .
=> fatal: Failed to resolve 'HEAD' as a valid ref.
It further turns out that there's a bug logged against the unhelpfulness of this in the mailing list.
And that the correct solution was right there in the Git status output (which, yes, I glossed over as 'crap)
... # Changes to be committed: # (use "git rm --cached <file>..." to unstage) ...
And the solution indeed is to use git rm --cached FILE
.
Note the warnings elsewhere here - git rm
deletes your local working copy of the file, but not if you use --cached. Here's the result of git help rm
:
--cached Use this option to unstage and remove paths only from the index. Working tree files, whether modified or not, will be left.
I proceed to use
git rm --cached .
to remove everything and start again. Didn't work though, because while add .
is recursive, turns out rm
needs -r
to recurse. Sigh.
git rm -r --cached .
Okay, now I'm back to where I started. Next time I'm going to use -n
to do a dry run and see what will be added:
git add -n .
I zipped up everything to a safe place before trusting git help rm
about the --cached
not destroying anything (and what if I misspelled it).
Solution 3
If you type:
git status
Git will tell you what is staged, etc., including instructions on how to unstage:
use "git reset HEAD <file>..." to unstage
I find Git does a pretty good job of nudging me to do the right thing in situations like this.
Note: Recent Git versions (1.8.4.x) have changed this message:
(use "git rm --cached <file>..." to unstage)
Solution 4
To clarify: git add
moves changes from the current working directory to the staging area (index).
This process is called staging. So the most natural command to stage the changes (changed files) is the obvious one:
git stage
git add
is just an easier-to-type alias for git stage
Pity there is no git unstage
nor git unadd
commands. The relevant one is harder to guess or remember, but it is pretty obvious:
git reset HEAD --
We can easily create an alias for this:
git config --global alias.unadd 'reset HEAD --'
git config --global alias.unstage 'reset HEAD --'
And finally, we have new commands:
git add file1
git stage file2
git unadd file2
git unstage file1
Personally I use even shorter aliases:
git a # For staging
git u # For unstaging
Solution 5
An addition to the accepted answer, if your mistakenly-added file was huge, you'll probably notice that, even after removing it from the index with 'git reset
', it still seems to occupy space in the .git
directory.
This is nothing to be worried about; the file is indeed still in the repository, but only as a "loose object". It will not be copied to other repositories (via clone, push), and the space will be eventually reclaimed - though perhaps not very soon. If you are anxious, you can run:
git gc --prune=now
Update (what follows is my attempt to clear some confusion that can arise from the most upvoted answers):
So, which is the real undo of git add
?
git reset HEAD <file>
?
or
git rm --cached <file>
?
Strictly speaking, and if I'm not mistaken: none.
git add
cannot be undone - safely, in general.
Let's recall first what git add <file>
actually does:
If
<file>
was not previously tracked,git add
adds it to the cache, with its current content.If
<file>
was already tracked,git add
saves the current content (snapshot, version) to the cache. In Git, this action is still called add, (not mere update it), because two different versions (snapshots) of a file are regarded as two different items: hence, we are indeed adding a new item to the cache, to be eventually committed later.
In light of this, the question is slightly ambiguous:
I mistakenly added files using the command...
The OP's scenario seems to be the first one (untracked file), we want the "undo" to remove the file (not just the current contents) from the tracked items. If this is the case, then it's ok to run git rm --cached <file>
.
And we could also run git reset HEAD <file>
. This is in general preferable, because it works in both scenarios: it also does the undo when we wrongly added a version of an already tracked item.
But there are two caveats.
First: There is (as pointed out in the answer) only one scenario in which git reset HEAD
doesn't work, but git rm --cached
does: a new repository (no commits). But, really, this a practically irrelevant case.
Second: Be aware that git reset HEAD
can't magically recover the previously cached file contents, it just resynchronises it from the HEAD. If our misguided git add
overwrote a previous staged uncommitted version, we can't recover it. That's why, strictly speaking, we cannot undo [*].
Example:
$ git init
$ echo "version 1" > file.txt
$ git add file.txt # First add of file.txt
$ git commit -m 'first commit'
$ echo "version 2" > file.txt
$ git add file.txt # Stage (don't commit) "version 2" of file.txt
$ git diff --cached file.txt
-version 1
+version 2
$ echo "version 3" > file.txt
$ git diff file.txt
-version 2
+version 3
$ git add file.txt # Oops we didn't mean this
$ git reset HEAD file.txt # Undo?
$ git diff --cached file.txt # No dif, of course. stage == HEAD
$ git diff file.txt # We have irrevocably lost "version 2"
-version 1
+version 3
Of course, this is not very critical if we just follow the usual lazy workflow of doing 'git add' only for adding new files (case 1), and we update new contents via the commit, git commit -a
command.
* (Edit: the above is practically correct, but still there can be some slightly hackish/convoluted ways for recovering changes that were staged, but not committed and then overwritten - see the comments by Johannes Matokic and iolsmit)
oz10
[Tools I use] UnitTest++ Boost LibBeecrypt SQLite3 CppSQLite stxxl( learning ) [Build Tools] meson cmake scons make nmake mpc (learning) [Compilers] clang aocc MSVC 2012 MSVC 2010 MSVC 2008 MSVC .NET 2005 MSVC .NET 2003 MSVC 6.0 GCC 4.8+ GCC 4.x GCC 3.3
Updated on July 08, 2022Comments
-
oz10 almost 2 years
I mistakenly added files to Git using the command:
git add myfile.txt
I have not yet run
git commit
. Is there a way to undo this, so these files won't be included in the commit?-
Admin almost 11 yearsStarting with Git v1.8.4, all the answers below that use
HEAD
orhead
can now use@
in place ofHEAD
instead. See this answer (last section) to learn why you can do that. -
Daniel Alder about 10 yearsI made a little summery which shows all ways to unstage a file: stackoverflow.com/questions/6919121/…
-
Hamzahfrq over 7 yearsIf you use Eclipse, it is as simple as unchecking the files in the commit dialogue box
-
jasonleonhard about 7 yearsThis is a great resource straight from Github: How to undo (almost) anything with Git
-
Sazzad Hissain Khan almost 7 yearsBefore you post a new answer, consider there are already 25+ answers for this question. Make sure that your answer contributes what is not among existing answers
-
Nesha Zoric almost 6 yearsI always make this work by running
git reset <file_name>
. For more info be sure to take a look at this article. -
Uğur Gümüşhan about 4 yearsif readers like to use GUI, you can right-click a file and click reset, or unstage
-
Dennis about 3 years
git rm --cached <file>
unstages and untracks (marked for removal on next commit) a given file, whilegit reset HEAD <file>
just unstages the file -
Sunwoo Yang about 2 yearsFor people working with large repos, you can also just cancel the git adding process and it'll revert back automatically.
-
-
Claudio Pierard over 14 yearsDoesn't just "git reset" without . do what you want, or am I missing something?
-
oz10 over 14 yearsI wasn't looking to un-add everything, just ONE specific file.
-
Tiago about 14 yearsOne tip is to copy your .git/config file if you have added remote origin, before deleting the folder.
-
Adrian Macneil about 13 yearsHah. I followed this same process. Except I gave up and said
rm -rf .git
,git init
because I didn't trustgit rm --cached
to keep my working copy. It says a little for how git is still overly complex in some places.git unstage
should just be a stock standard command, I don't care if I can add it as an alias. -
SamGoody almost 13 yearsDid this and it deleted all my other existing files - unchanged - from the git backup. Re-adding them makes everything larger and destroys the proper history. Git is totally an unfinished project.
-
Tom Davies over 12 yearsin recent versions of git (v1.7.1.1 tested )
git rm -r --cached .
works fine -
Marius Butuc over 12 yearsIf you like
git reset
, trygit reset *
instead ofgit reset .
- it un-stages all you previously staged files. -
jlundqvist almost 12 yearsInstead of the dry run, walk through the add with
git add -p
-
drahnr over 11 yearsFor me git says
git reset HEAD <File>...
-
Kounavi over 11 yearsConfirmed! Tried a git reset after a git add . and git was complaining about corrupt HEAD. Following your advice, I could git add & reset back and forth with no problems :)
-
chachan over 11 yearsYou also could use
git stash/git stash pop
to avoid zipping/backing up everything -
oz10 about 11 yearsAs it happens, there was a last commit... but I was specifically asking about removing a single file from the commit, not every file from the commit.
-
Barry Kelly about 11 yearsgit rm --cached <file> is actually the correct answer, if it is the initial import of <file> into the repository. If you're trying to unstage a change to the file, git reset is the correct answer. People saying that this answer is wrong are thinking of a different question.
-
Admin about 11 years@ChrisJohnsen comment is spot on. Sometimes, you want to commit all files except one:
git add -A && git rm --cached EXCLUDEFILE && git commit -m 'awesome commit'
(This also works when there's no previous commits, reFailed to resolve 'HEAD'
problem) -
sjas about 11 yearsThe second part works, but it is a bit clumsy. How line endings are handled, depends on
autocrlf
value... This won't work in every project, depending the settings. -
naught101 about 11 yearsThis will actually work, but only on the first commit, where the file didn't exist before, or where the
git add
command added new files, but not changes to existing files. -
takeshin about 11 yearsMind that the
--cached
is a really important part here. -
leonbloy almost 11 yearsThe message will be different depending on whether the
add
ed file was already being tracked (theadd
only saved a new version to the cache - here it will show your message). Elsewhere, if the file was not previously staged, it will displayuse "git rm --cached <file>..." to unstage
-
leonbloy almost 11 yearsOf course, this is not a true undo, because if the wrong
git add
overwrote a previous staged uncommited version, we can't recover it. I tried to clarify this in my answer below. -
Alex North-Keys almost 11 yearsSure, but then you have the followup question of how one should unadd one of two (or more) files added. The "git reset" manual does mention that "git reset <paths>" is the opposite of "git add <paths>", however.
-
Priya Ranjan Singh almost 11 yearsAlso helpful if you don't have any previous commits. In absence of previous commit,
git reset HEAD <file>
would sayfatal: Failed to resolve 'HEAD' as a valid ref.
-
deed02392 almost 11 yearsI certainly feel if this is a totally new repository, removing the
.git
directory and initialising again is the best way. For cases in a well-used repo where you just accidentally added a single file,git rm --cached <file>
seems best although I get a scarydelete mode 100644 file
after my commit. -
jeswang over 10 yearsI can't under stand the difference of 'git reset head <file>' and 'git rm --cached <file>. Could you explain it?
-
sjas over 10 years@jeswang files are either 'known' to git (changes in them are being tracked.), or they are not 'versioned'.
reset head
undoes your current changes, but the file is still being monitored by git.rm --cached
takes the file out of versioning, so git no longer checks it for changes (and also removes eventually indexed present changes, told to git by the prioradd
), but the changed file will be kept in your working copy, that is in you file folder on the HDD. -
akostadinov over 10 yearsaccording to
git status
output of git version 1.8.1.4 the correct way to unstage new files is:git reset HEAD <file>...
-
boulder_ruby over 10 years
git reset HEAD *.ext
whereext
is the files of the given extension you want to unadd. For me it was*.bmp
&*.zip
-
Admin about 10 yearsI tried
git reset <path>
and it works just fine without a separator. I'm also using git 1.9.0. Maybe it doesn't work in older versions? -
Luc almost 10 yearsActually, this does not reset every file because * uses shell expansion and it ignores dotfiles (and dot-directories).
-
Luc almost 10 yearsMind that * will usually not include dotfiles or 'dot-directories' unless you explicitly specify
.*
or.*.prj
-
Zorayr almost 10 yearsYou can run
git status
to see anything remaining and reset it manually i.e.git reset file
. -
ahnbizcad almost 10 yearsjust goes to show how unintuitive and convoluted git is. instead of having parallel "undo" commands, you have to find out how to undo them. Like trying to free your leg in quick sand, and then getting your arm stuck, then getting your other arm stuck... every command should be done through GUI, with dropdown menus items for the options... Think of all the UI, productivity gains we've had, but we have this mess of a retro command line interface. It's not like the git GUI programs make this any more intuitive.
-
JoeMoe1984 almost 10 years@BarryKelly no it is not the correct answer. What you actually want to do is either
git reset
to undo all added files orgit reset <file>
to undo a specific added file.git rm --cached
may work on the surface but what actually happens is it removes it from the tracking history as well which is not what you would want to do, unless, you added that file to a gitignore file where that file shouldn't have been tracked in the first place then in that case it would be ok. -
Barry Kelly almost 10 years@JoeMoe1984 git reset doesn't work on empty repos (initial imports)
-
JoeMoe1984 almost 10 years@BarryKelly I tried to edit my comment as I reread yours but I was too late. I missed that part of what you wrote ;). But yeah you're right, that would be another instance to use
git rm --cached
-
Alexander Suraphel over 9 yearsYes I understand that. I only wanted to implicitly suggest that your indicate that on your answer like "You can use
git-gui
...." :) -
DrewT over 9 yearsThe difference is
git reset HEAD <file>
is temporary - the command will be applied to the next commit only, butgit rm --cached <file>
will unstage untill it gets added again withgit add <file>
. Also,git rm --cached <file>
means if you push that branch to the remote, anyone pulling the branch will get the file ACTUALLY deleted from their folder. -
PositiveGuy over 8 yearsgit reset said it undid the changes but when I proceeded to do another git status, they still showed modified
-
rew over 8 yearsWhen intially populating a git repository, "git reset" from the top answer doesn't work: failed to resolve HEAD. We added a single file too many to the initial commit. As suggested by this answer, in that case "git rm --cached <file>" works for me. Maybe "git rm --cached ." does more than is intended for some people, but (as suggested by git status), git rm --cached <file> works....
-
Mark Amery over 8 yearsNo, this adds a deletion of everything in your current directory. Very different to just unstaging changes.
-
Mark Amery over 8 yearsThis answer was reasonable at the time it was posted, but is now obsolete;
git reset somefile
andgit reset
both work prior to making the first commit, now. This has been the case since several Git releases back. -
Mark Amery over 8 years-1; no, this doesn't un-stage the file, it stages a deletion of the file (without actually deleting it from your work tree).
-
Mark Amery over 8 years+1. An extraordinary number of highly-upvoted answers and comments on this page are just flat-out wrong about the behaviour of
git rm --cached somefile
. I hope this answer makes its way up the page to a prominent position where it can protect newbies from being misled by all the false claims. -
Mark Amery over 8 years"I'm surprised that no one mention interactive mode" - they did: stackoverflow.com/a/10209776/1709587
-
andriy over 8 years@MarkAmery, you may be right (it'd be cool if you posted a source for your assertion), but there's still value in starting your repo with a clean commit or two.
-
Jonny about 8 yearsSo the opposite of "add" is "reset"? What about "remove"?
-
Wildcard about 8 years@Jonny, the index (aka staging area) contains all the files, not just changed files. It "starts life" (when you check out a commit or clone a repo) as a copy of all the files in the commit pointed to by HEAD. So if you remove a file from the index (
git rm --cached
) it means you are preparing to make a commit that deletes that file.git reset HEAD <filename>
on the other hand will copy the file from HEAD to the index, so that the next commit won't show any changes being made to that file. -
Kevin Lee about 8 yearsWhy not just delete the hidden .git folder lol.. and do git init again... (assuming you're making the git repo for the FIRST time and have not done any commits)
-
donquixote almost 8 yearsI just discovered that there is a
git reset -p
just likegit add -p
. This is awesome! -
Ding-Yi Chen over 7 yearsIf the files have not yet in index, use
git rm --cache <filename>
, if the files already in index, but you don't want them to be in this commit, usegit reset <filename>
-
machineghost over 7 years
-p
most definitely is awesome, and it's used in a lot of git commands (not just reset and add). But to answer @WeDoTDD.com and @Johnny,git reset
by itself just clears whether Git "knows about" the changes; it doesn't clear the changes themselves. To do that you need to dogit checkout someFile.txt
(for individual files) orgit reset --hard
(to wipe everything clean). There's no going back from either of these commands though, so be very careful when using them. -
Arthur about 7 yearsbut 'git reset file' removes other files that had been staged for commit too. not good.
-
Unbreakable about 7 yearsSuppose I am at 1st pic meaning meaning I have not even did "git.add". Also, I not at all want all this change. I mean when I do git status, it should not show any red files. I mean it should be in sync as if there was not a single file altered since the last git push. how to achieve that.
-
Unbreakable about 7 yearsSO suppose you are just at step first. And you want to get rid of all the changes you have done which is making "newFile.txt" to come up as red.
-
Unbreakable about 7 yearsWhen I do git status. I should not see any change at all. All the red files should get reverted.
-
Vidura Mudalige about 7 yearsHi, I think your question is how to remove untracked files from the current tree. For that, you can use "git clean -f -d". This will remove untracked directories as well.
-
Vidura Mudalige about 7 yearsIf you don't want to delete the untracked files, just ignore "-f" flag.
-
Unbreakable about 7 yearsIt did not work. Suppose I did a git push. Now if I add a single line in my code and check git status. It will show a file in Red colour. Suppose I do not want that one line change at all. One option is I can do cntrl + z. But I want git to do that for me. I want my local project to get in sync with the master repo. I mean when I do "git status" then I should see message as "Its in sync with the master". And when I open my code I should have a message like "some external source is making changes" and when I say "Yes" to that prompt then the one line change that I had made shold be gone.
-
Unbreakable about 7 yearsbasically I want a git command which will revert all the changes which is making the git status to show "red files"
-
Unbreakable about 7 yearsSo I made a change to a file. I did not do anything else. NO git command at all (no git push not even git add or git commit). But now I want a git command which will revert those changes in my local repo.
-
Unbreakable about 7 yearsIn a more technical terms "How to revert the file changes made in local repo which has not been put in the staging area"
-
Vidura Mudalige about 7 yearsDidn't you try "git checkout file_name". Also, you can stash the changes by using "git stash".
-
Thomas Weller almost 7 years"moves"? This would indicate it has gone from the working directory. That's not the case.
-
Thomas Weller almost 7 yearsThis may have been applicable at the time of writing but seems to work now.
-
Lenar Hoyt almost 7 yearsWhy is it obvious?
-
ozkary over 6 yearsGit reset without Head uses the current staged files. Use git reset head to specified a different commit. Like git reset Head~2 to go back to a previous commits. 2 is number of commits
-
Peter Schneider over 6 yearsYou actually can recover overwriten previously staged but uncommited changes but not in a userfriendly way and not 100% secure (at least none I had found): goto .git/objects, search for files created at the time of
git add
you want to recover (61/3AF3...
-> object id613AF3...
), thengit cat-file -p <object-id>
(might be worth it to recover several hours of work but also a lesson to commit more often...) -
Parinda Rajapaksha over 6 yearsIt says, "git-gui: command not found". I'm not sure if this works.
-
Johannes Matokic over 6 yearsStrictly speaking there is a way to recover an already staged file that was replaced with git add. As you mention git add creates an git object for that file that will become a loose object not only when removing the file completely but also when being overwritten with new content. But there is no command to automatically recover it. Instead the file has to be identified and extracted manually or with tools written only for this case (libgit2 will allow this). But this will only pay out if the file is very important and big and could not be rebuild by editing the previous version.
-
Johannes Matokic over 6 yearsTo correct myself: Once the loose object file is found (use meta-data like creation date/time)
git cat-file
could be used to recover its content. -
Trent over 6 yearsPlease explain the difference between
git reset <file>
andgit checkout <file>
. -
Jelle De Loecker about 6 yearsGreat! The
git reset HEAD <file>
one is the only one that will work in case you want to unstage a file delete -
franc about 6 yearsreset doesn't change the file, just put it away from the stage (=index, where it was put by git add)
-
Hasib Kamal Chowdhury about 6 yearscheckout change the codes in file and move to the last updated state. reset doesn't change the codes it just reset the header. As example, reset use for added or committed files resetting before push and checkout use for back to the last updated/committed stage before git add.
-
SilverWolf about 6 yearsMy git version 2.14.3 says
git reset HEAD
to unstage. -
iolsmit almost 6 yearsAnother way to recover changes that were staged but not committed and then overwritten by e.g. another
git add
is viagit fsck --unreachable
that will list all unreachable obj, which you can then inspect bygit show SHA-1_ID
orgit fsck --lost-found
that will >Write dangling objects into.git/lost-found/commit/
or.git/lost-found/other/
, depending on type. See alsogit fsck --help
-
iolsmit almost 6 yearsAnother way to recover changes that were staged but not committed and then overwritten by e.g. another
git add
is viagit fsck --unreachable
that will list all unreachable obj, which you can then inspect bygit show SHA-1_ID
orgit fsck --lost-found
that will >Write dangling objects into.git/lost-found/commit/
or.git/lost-found/other/
, depending on type. See alsogit fsck --help
-
Imam Bux over 5 yearsreset = remove the file from stage however changes will still be there. checkout = gets the updated file from the repository and will overrides the current file
-
Obsidian over 5 yearsActually,
git stage
is the alias forgit add
, which is the historic command, both on Git and other SCM. It has been added in december 2008 with commit 11920d28da in the "Git's git repository", if I can say. -
Vladimir Despotovic over 5 yearsThis is also a wrong answer. I don't know why people post answers, and even less why they upvote wrong answers....
-
bhavya_w about 5 yearsThis command CLEARS / DELETES STUFF IN THE INDEX. What the OP and other people actually want is to UNDO THE CHANGES IN THE INDEX and NOT DELETE STUFF. Git reset . is the correct answer.
-
Irfandy Jip about 5 yearsWow, this is much simple then doing command lines which you don't understood. This is definitely recommended for a beginner like me. Thanks for writing this up!
-
Creos almost 5 yearsone of the best answers on here, sadly it is quite low on the list
-
Sagar Khatri over 4 yearsThanks. Didn't want to risk it so had to use GUI.
-
Peter Mortensen over 4 yearsYes, the same technique can be used with TortoiseGit, getting the Git commands for the common use cases.
-
Peter Mortensen over 4 yearsImage: "The command add..." → "The command adds..." (present simple tense, third person)
-
Peter Mortensen over 4 yearsImage: wanna → want to (there is no need to use slang here)
-
Bill Hoag over 4 yearsAs of git 2.23.0, there is now
"git restore --staged <file>..." to unstage
. See stackoverflow.com/a/16044987/40422 -
akgupta over 4 yearsI have also added some files from a common library to the stage. Since, it is an angular app, so I had to use
git reset */commonlib/styles/*.scss
to locate all such files and it worked. -
Rohit Chaurasiya about 4 yearsgit reset [file name] ex : git reset src/main/java/com/dao/ImportCsvDataDaoImpl.java
-
TheTechRobo Stands for Ukraine almost 4 years@ahnbizcad ...well, once you know what you're doing, it's much easier,...and I find the GUI too bloated and too much mouse movement...so it's a matter of opinion.
-
Jonathan Leffler over 3 yearsIf you decide to answer an older question that has well established and correct answers, adding a new answer late in the day may not get you any credit. If you have some distinctive new information, or you're convinced the other answers are all wrong, by all means add a new answer, but 'yet another answer' giving the same basic information a long time after the question was asked usually won't earn you much credit. You've added 'pretty pictures' — I'm not convinced they're all that beneficial. They'd be illegible if I was using a cell phone to read this answer.
-
crobar over 3 yearsI don't know if I did this right, but
git reset <file>
seemed to also delete the file from my file system as well, which is obviously not what you want. -
Jonathan Leffler over 3 yearsWelcome to Stack Overflow. If you decide to answer an older question that has well established and correct answers, adding a new answer late in the day may not get you any credit. If you have some distinctive new information, or you're convinced the other answers are all wrong, by all means add a new answer, but 'yet another answer' giving the same basic information a long time after the question was asked usually won't earn you much credit.
-
prosoitos over 3 yearsSince Git v2.23 the message has changed yet again. It now says
git restore --staged <file>
. See my answer below for an update. -
Ahmad over 3 yearsI just discovered that there is a git reset -p just like git add -p. This is awesome!
-
Jonathan Leffler almost 3 yearsIf you
source
the file, it does not need to be executable. -
Jonathan Leffler almost 3 yearsHave you considered using a
.gitignore
file to prevent the files and directories that should not be added from being added? -
Vladimir Ch over 2 yearsjust what i searched
git checkout -- <file>
thanx ! -
Ulf Aslak over 2 yearsThis is a great answer!
-
Valerij Dobler over 2 yearsif it was your first commit Just remove the .git directory and init again.
-
fresko over 2 yearsI agree, it's very annoying that Linus Torvalds, instead of creating simmetric commands, just created a new word for a different command. For simmetric i mean something like: commit - uncommit; stage-unstage . Or a keyword UNDO that can be used for many commands: git commit X - git UNDO commit x. Seems natural that one has to learn by heart a lot of words. The ones that are used not so often are easily forgotten... and here we all are on this page
-
Dan Dascalescu over 2 yearsThanks for the updated answer. Can you detail how
git restore --staged .
differs fromgit reset .
? -
Dan Dascalescu over 2 years
*
is not a command. It's a wildcard. -
Dan Dascalescu over 2 yearsWhat does this answer provide in addition to the top answer?
-
Dan Dascalescu over 2 yearsHow is this answer any better than the top one, which was given 8 years earlier? @PeterMortensen, you edited this - why not flag for deletion as a duplicate?
-
prosoitos over 2 yearsDoes this thread answer your question @DanDascalescu?
-
abdulwasey20 almost 2 years
git: 'gui' is not a git command. See 'git --help'.