GIT - 4.12 Manage files outside of GIT

This lesson shows what happens when you rename, move or delete files using only the operating system (without going through Git), and how to reconcile those changes with the index afterwards. The starting point is a clean repository on master containing coucou.html and venus.html.

First we create a brand new file with the shell command touch uranus.html. Then we rename Venus by changing both its name and its extension at the OS level:

mv venus.html venus.txt

Running git status shows two interesting things. The new file uranus.html appears as untracked, which is expected. But the rename is not recognized as a rename: Git sees it as a deletion of venus.html plus an untracked venus.txt. That is the price of bypassing git mv.

Catching up with git add -u and git add -A

  • git add -u (update) stages only modifications and deletions of already tracked files. Untracked new files are ignored.
  • git add -A (all) covers everything — modifications, deletions, and new untracked files.

With git add -A, Git correctly detects that venus.html was renamed to venus.txt, and also stages the new file uranus.html. We then commit everything together:

git commit -m "rename and add"

If we later decide we no longer want uranus.html, we can also delete it at the OS level using the shell rm command:

rm uranus.html
git add -u
git commit -m "delete uranus.html"

git add -u picks up the deletion and stages it; the commit then records the removal. The key takeaway is that Git does notice OS-level operations, but it sometimes interprets them differently (renames as delete+add) and you must remember to refresh the index with -u or -A before committing.

Summary

This lesson demonstrates how Git tracks file changes when modifications are made using system-level commands outside of Git itself. You'll learn how renaming and deleting files with shell commands like `mv` and `rm` are detected by Git, and how to properly stage these changes using different `git add` variants to ensure they're correctly reflected in your repository.

Key points

  • When files are renamed or deleted using shell commands (`mv`, `rm`), Git recognizes them as separate deletion and addition operations rather than a single rename
  • `git add -u` updates only deletions and modifications of tracked files, while `git add -A` stages all changes including new untracked files
  • `git status` shows renamed files as deletions of the old filename and additions of the new filename until they are properly staged
  • Using `git add -A` is the most comprehensive approach to capture all types of modifications (additions, deletions, and renames) in your working directory
  • Changes must be staged and committed to finalize file management operations in the repository version history

FAQ

Why does Git show a renamed file as both a deletion and addition?

When you rename a file using shell commands (`mv`), Git sees the old filename disappear and a new filename appear separately. Git only recognizes this as an actual rename after the changes are properly staged and committed; until then, it treats it as two separate operations.

What's the difference between `git add -u` and `git add -A`?

`git add -u` (update) stages only modifications and deletions of already-tracked files, while `git add -A` stages all changes including new untracked files, making it more comprehensive for capturing all modifications in your working directory.

Do I need to use `git rm` and `git mv` instead of shell commands?

While `git rm` and `git mv` directly inform Git about these operations, using shell commands (`rm`, `mv`) works equally well—Git will detect and properly track the changes if you stage them correctly with `git add -A` or by selectively using `git add -u` for deletions only.