Git fundamentals
Theory: Working Directory
After cloning hexlet-git, we can see the .git directory inside and the files we added. What happens if you try to delete one of the files?
Git tells you when a file has been deleted and offers commands to restore or commit changes. It's worth stopping here and diving a bit into how git works. How does it even know that the file has been deleted?
Inside the project directory, we can see the project files on one side and the .git directory on the other. The repository is the .git directory. It stores all the information about what changes were made, as well as the changes themselves. But everything outside is the so-called working directory. These files (and directories, if any) are extracted from .git at the time of cloning. Every time we make a change to the working directory, git compares the modified files with the files inside .git, i.e., their state at the time of the last commit. If there are changes to the last committed version, git will tell us in the git status output.
This is very easy to see if you follow git's advice in the output above and restore the deleted file:
You can delete the entire working directory and then restore it without any problems. This helps us achieve something very important - we've made it possible to quickly restore the latest version of the code if the changes we made don't suit us anymore. Or we can commit them, if necessary:
There's something important you need to take note of. Whether we delete, add or change a file, the commit procedure does not change. After changes are made, we always perform a git add, which prepares the change for a commit (it doesn't add a file!), then we perform the commit itself.
By the way, git has a command called git rm that combines deletion and commit preparation:

