Ignoring Files with Gitignore

Introduction

In software development, your project folder can get cluttered with files that shouldn't be shared. These might include:

Temporary files: Generated by your editor or OS (e.g., .DS_Store).
Build artifacts: Compiled code (e.g., .exe, .class).
Logs: Files recording program execution (e.g., debug.log).
Secrets: API keys or passwords (NEVER commit these!).

Git has a feature called .gitignore. It is a simple list of "do not track" rules. If a file matches a rule in this list, Git will leave it untracked by default.

This is a policy mechanism for the working tree. It tells Git which untracked files should be treated as normal background noise rather than potential source files to add.

This is not just about tidiness. A good .gitignore helps prevent noise, oversized repositories, and accidental commits of secrets or machine-specific junk.

In this lab, you will:

Create a "junk" file that we want to ignore.
Configure a .gitignore file.
Verify that Git successfully ignores the junk file.

Create a Log File

First, let's create a file that represents "junk" data. Imagine your application generates a log file every time it runs. We want to keep this file on our local machine for debugging, but we do not want to share it with the team or save it to history.

Navigate to the project directory:

cd ~/project

Create a file named debug.log with some dummy content:

echo "System started at $(date)" > debug.log

Verify it exists:

ls

At this point, if you run git status, Git will see this file as "Untracked" and will keep pestering you to add it.

That is the normal behavior for files Git notices but is not yet ignoring. Git is effectively asking whether the file should become part of the repository.

Create the .gitignore File

To tell Git to stay silent about certain files, we need a special configuration file named .gitignore.

Create the file in your project root:

touch .gitignore

Verify it was created (remember it's hidden because it starts with a dot):

ls -a

The .gitignore file is just a plain text file. Usually, you do want to commit the .gitignore file itself, so that everyone on your team shares the same ignore rules.

That is an important distinction: ignored files are usually local artifacts, but .gitignore itself is usually project configuration and belongs in version control.

Configure Ignore Rules

Now, let's add a rule to ignore all log files.

We can use the wildcard * to say "anything ending in .log".

Add the pattern *.log to your .gitignore file:

echo "*.log" > .gitignore

Verify the file content:

cat .gitignore

Output:

*.log

This single line tells Git: "Ignore any file in this directory (and any subdirectory) if its name ends with .log".

Ignore rules are pattern-based, not one-file-only instructions. That is why a short .gitignore file can manage many categories of generated or unwanted files.

Verify Ignore Status

Let's test if the rule is working.

Run git status:

git status

Analyze the output:

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    .gitignore

Wait! Where is debug.log?

It's gone from the list! This means Git is successfully ignoring it. Git is only telling you about .gitignore itself (which we should eventually commit), but debug.log is invisible to Git.

This is the practical difference between untracked and ignored. Untracked files are still being suggested for addition, while ignored files are intentionally excluded from that attention.

If you want to be double-sure, you can use the check-ignore command to ask "Why is this file ignored?":

git check-ignore -v debug.log

Output:

.gitignore:1:*.log debug.log

This translates to: "The file debug.log is ignored because of the rule *.log on line 1 of .gitignore."

Summary

In this lab, you learned how to keep your repository clean.

Key Takeaways:

.gitignore: A text file listing patterns for Git to ignore.
Wildcards: Use * to match multiple files (e.g., *.log).
Untracked vs Ignored: An ignored file is treated as if it doesn't exist in the eyes of Git versions (though it still exists on your disk).

This simple file is powerful. It stops you from accidentally committing temporary files, binaries, or sensitive keys, keeping your project professional and secure.