Skip to content

Git Level 3, Task 4: Cleaning the Working Directory with git clean

Today's task was about a very common and practical scenario: a developer had mistakenly created some test files in a repository, and these files were not part of the project. My objective was to "clean" the repository by removing these extra files, ensuring that git status would show a clean working tree.

This was a great lesson in Git housekeeping. It taught me about "untracked files" and the git clean command, which is the specific tool for this job. It also reinforced the importance of understanding Linux file permissions, as the repository was in a root-owned directory.

Table of Contents

The Task

My objective was to clean up a "dirty" Git repository on the Storage Server. The specific requirements were: 1. Work within the /usr/src/kodekloudrepos/cluster Git repository. 2. The repo had extra, uncommitted files created by a developer. 3. I had to remove these files so that git status would report nothing to commit, working tree clean. 4. I was not to add or push any new commits.

My Step-by-Step Solution

The process required me to first investigate the "dirty" state of the repo and then use the git clean command to fix it. As the repository was in a root-owned directory, all commands required sudo.

Phase 1: Investigation

  1. I connected to the Storage Server (ssh natasha@ststor01) and navigated to the repository (cd /usr/src/kodekloudrepos/cluster).
  2. This was the critical first step. I ran git status to see what Git was seeing. 
    sudo git status
    The output showed an "Untracked files" section, listing the extra files (e.g., test1.txt, temp.log) that the developer had mistakenly created. This confirmed the repository was not clean.

Phase 2: The Cleanup

  1. With the problem identified, I executed the git clean command. This command is designed to remove untracked files.
  2. Because git clean is a destructive command (it deletes files permanently), it requires the -f (force) flag to run. I also used the -d flag to remove any untracked directories, not just files. 
    sudo git clean -fd

Phase 3: Verification

The final step was to confirm that the repository was now clean. 1. I ran git status one more time. 

sudo git status
2. The output was now: On branch master \n nothing to commit, working tree clean. This was the definitive proof that I had successfully removed all untracked files and completed the task.

Why Did I Do This? (The "What & Why")

- Untracked Files: These are files in your working directory that Git is not aware of. They have not been "staged" (with git add) and are not part of any previous commit. These are often build artifacts (.log, .o files), temporary editor files, or files created by mistake, as in this task. - git status: This is the most important command for understanding the state of your repository. A "clean" status means your working directory and staging area perfectly match the last commit (HEAD). A "dirty" status means you have uncommitted changes or untracked files. - git clean: This is the specific command to solve this problem. It's a housekeeping utility that "cleans" your working directory by removing untracked files. - Why not git reset --hard? The git reset command (which I used in a previous task) is for undoing committed changes. My problem here was not with bad commits, but with extra files that had never been committed. git clean is the correct tool for this.

Deep Dive: The State of Files in Git

This task was a perfect lesson in the different states a file can be in within a Git repository.

[Image of Git file status lifecycle]

  1. Untracked: The file exists in your working directory, but Git has no record of it and is not watching it for changes. This was the state of the mistaken files.
  2. Tracked (Unmodified): The file is known to Git and matches the version in the last commit. This is the "clean" state.
  3. Tracked (Modified): The file is known to Git, but you have changed it since your last commit. git status shows this under "Changes not staged for commit."
  4. Staged: You have run git add on a modified or new file. It is now in the "staging area," ready to be included in the next commit.

My task was to deal with files in the "Untracked" state. The git clean command is the only command that directly targets and removes these files.

Common Pitfalls

- Forgetting sudo: In this specific lab environment, the repository was owned by root. Forgetting to use sudo for git status or git clean would have resulted in a "Permission denied" or "fatal: not a git repository" error. - Accidentally Deleting Important Files: git clean is destructive and irreversible. A common mistake is to run git clean -fd without first running git status to see what will be deleted. It's a good practice to run git clean -fdn first. The -n flag performs a "dry run" and will show you a list of the files it would delete, so you can double-check. - Trying to use git reset: Using git reset --hard would not have solved this problem. That command only affects files that are tracked by Git. It has no effect on untracked files.

Exploring the Commands I Used

- ssh natasha@ststor01: The standard command to Secure SHell into the storage server. - cd /usr/src/kodekloudrepos/cluster: The change directory command, used to navigate into the correct Git repository. - sudo git status: My primary investigation tool. It shows the current state of the repository, including any "Untracked files." - sudo git clean -fd: The main command for this task. - git clean: The command to remove untracked files. - -f: The force flag, which is required because the command is destructive. - -d: An additional flag that tells git clean to also remove untracked directories, not just files.