Git - Delete Operation

Git - Deleting Files

To remove files from your Git repository, you should use the git rm command. This command not only removes the file from your working directory but also stages the deletion, so Git knows the file is intentionally removed from version control.

Simply deleting a file with the standard rm (Linux/macOS) or del (Windows) command only removes it from your working directory. Git will see it as a missing file, and you would then need to git add the deletion. git rm handles both steps.

Example: Deleting a Tracked File

Imagine Tom’s project has an accidentally committed compiled binary file named app_binary in the bin/ directory. Version control systems like Git are primarily for source code, not compiled artifacts.

Current state:

[tom@dev-machine project]$ ls bin/
app_binary  helper_script.sh

[tom@dev-machine project]$ git status bin/app_binary
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean
(assuming app_binary was previously committed)

Tom decides to remove app_binary from the repository. He uses git rm:

[tom@dev-machine project]$ git rm bin/app_binary
rm 'bin/app_binary'

[tom@dev-machine project]$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
  deleted:    bin/app_binary

The git status output shows that the deletion of bin/app_binary is staged. The file is also removed from Tom’s working directory.

Tom now commits this change:

[tom@dev-machine project]$ git commit -m "Remove compiled binary from version control"
[main 5776472] Remove compiled binary from version control
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100755 bin/app_binary

After committing, he should push this change to the remote repository:

[tom@dev-machine project]$ git push origin main

Other collaborators, upon pulling, will also have this file removed from their working directories and their Git history updated.

Removing a File from Staging but Keeping it Locally

Sometimes, you might have accidentally staged a file (e.g., a configuration file with sensitive data or a large log file) that you don’t want to commit, but you still want to keep the file in your working directory. For this, use git rm --cached <file>.

[tom@dev-machine project]$ touch local_secrets.conf
[tom@dev-machine project]$ git add local_secrets.conf

[tom@dev-machine project]$ git status
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
  new file:   local_secrets.conf

[tom@dev-machine project]$ git rm --cached local_secrets.conf
rm 'local_secrets.conf'

[tom@dev-machine project]$ git status
Untracked files:
  (use "git add <file>..." to include in what will be committed)
  local_secrets.conf

[tom@dev-machine project]$ ls
local_secrets.conf # File still exists locally

git rm --cached removes the file from the staging area (and from being tracked by Git if it was already committed in the past and you are removing it from future tracking). The file itself remains in your working directory. You should then add such files to your .gitignore file to prevent them from being accidentally tracked again.

Best Practice: Use a .gitignore file to tell Git to ignore certain files or directories (like compiled binaries, log files, editor-specific files, or dependency folders like node_modules). This prevents them from being accidentally committed in the first place.