I just made a stage with:
git add .
When I wanted to reset, I used:
git rm .
Suddenly all the files are deleted!! I thought that it should be just the tree-working deleted, it acted like I did :
rm -rf ./*
Why did it delete all the files? And what command should I have used instead?
When you remove files from the index and the working tree, git will notice that files that you had in the current commit are now gone, and so git status will show that those files are deleted.
However, no need to panic. This is just Git's way of telling you that it sees those files gone compared to the prior commit. The files still exist in the repo. In fact, if you stage all the deletions and commit right now, you'll just have a new commit without the files, but your current commit will still exist with all the files in the repo. You can check it out at any time and it will restore those files back into the working directory.
Info on how to restore files from git rm is available in this answer.
Note: Be careful with:
git reset --hardThis will work in this case (per the other answers), but be a little careful with it - understand that while it will restore all files to the last (current) commit, that means you will lose all changes both in the index and the working directory. In this case, you really do want to restore all files (since the
git rm .deleted all of them), so that's not a problem.You can restore individual files to last commit status with
git reset --hard [filename]
Regarding what to do to remove the files from the staged area - I prefer using Git Extensions, which is a popular open source Git GUI tool. When you hit the "commit" button, it opens a window for committing that shows all staged and unstaged files with any changes, let's you click on any of them and see a diff of the changes, and there are buttons to move them between the working directory and index.
But if you want the command-line option, you can use this command:
git reset
will remove all files/changes from the index (Note: no period!!). Also, you can use:
git reset [filename]
to unstage just [filename] (or a filename pattern, like *.txt).
This is the same as using git reset --mixed, and causes git to set all files (or just [filename]) back to the state it was in at the current commit. The --mixed option only resets the index, not the working directory, so it won't remove any changes in the file, it will only make the file/changes(s) unstaged.
If you use git reset --soft it won't do anything - --soft doesn't reset either the index or the working directory, and since you don't specify a different branch or commit, it will reset all the files to the current commit with the existing index and working directory - which is what you already have!
If you use git reset --hard then it will clear both the index and the working directory and restore the file(s) to the original condition for the current commit - they will be unstaged with no changes - which is one solution to fixing your deletion problem.
If you wanted to reset your additions, you could have done
git reset --hard
Which will bring you back to the state before you did the git add ., and should restore any files that have disappeared.
All this reset did not work for me, and how I was scared! My situation: I had an empty repository and I had made 4 commits. What I needed to do was to go to a specific commit before the git rm took effect. So in my case, if the above does not work, try:
git log
git checkout <your-before-git-rm-commit>
