GIT - 4.13 Exclusion of unwanted files

This lesson explains how to tell Git to ignore certain files and folders so they never accidentally end up tracked or committed. The starting point is a clean test repository on master that contains venus.txt and coucou.html. We will simulate an application that produces log files during execution — typical examples of files that should never live in version control.

First we create a fake log file and add some random content to it:

touch application.log
code application.log     # then write a few lines and save

Right after the save, git status shows application.log as untracked. The risk is obvious: at the next git add . or git add -A, the log might end up in the repository. We do not want generated files in source control.

Creating a .gitignore file

Git provides a built-in mechanism for this: a special file named .gitignore. Each line is a pattern describing what to exclude. Instead of targeting just one file, we use a wildcard so every current and future log file is ignored:

code .gitignore

Inside the file we add:

*.log

Back in the terminal, git status no longer mentions application.log — Git is already honoring the exclusion. Note that .gitignore itself is a file that should be tracked by Git so the same rules apply to everyone cloning the project. We stage and commit it:

git add .gitignore
git commit -m "add gitignore"

The working directory is now clean. The log file still exists on disk, but it lives outside the repository's tracked content. To finish, we can simply delete it from the filesystem with rm application.log. The same pattern works for any generated artifact: build outputs, IDE caches, secrets, dependencies folders, etc. A good .gitignore is one of the first things you set up on any new project.

Summary

This lesson introduces .gitignore, Git's solution for excluding unwanted files from version control. Students learn why generated files like logs shouldn't be tracked, how to create and configure a .gitignore file using wildcard patterns such as *.log, and why the .gitignore file itself should be committed to the repository for team-wide consistency.

Key points

  • .gitignore file specifies which files and directories Git should ignore
  • Wildcard patterns like *.log exclude all matching files from tracking
  • Excluded files remain in the filesystem but disappear from version control
  • The .gitignore file should be committed to share exclusion rules with all team members
  • Generated files, logs, and build artifacts should never be tracked in the repository

FAQ

Why is it important to exclude certain files from Git?

Generated files (logs, build outputs, temp files) should not be tracked because they bloat the repository, cause unnecessary merge conflicts, and aren't part of the source code that needs version control.

How do wildcard patterns work in .gitignore?

Patterns like *.log match all files ending with .log, *.tmp matches temp files, and you can use * as a wildcard for any sequence of characters to create flexible exclusion rules.

Should the .gitignore file itself be committed?

Yes, .gitignore should be committed and pushed to the repository so all team members apply the same exclusion rules consistently across the project.