How to Use .gitignore to Exclude Files from Git Tracking

What is .gitignore?

A .gitignore file is a text file that tells Git which files or folders to ignore in a project. Ignored files are not tracked by Git, meaning they won’t be staged or committed. This is useful for files that are generated by your computer or build process, such as log files, compiled code, or dependency folders like node_modules.

Problem Scenario

When you run git status, you see a long list of untracked files that you don’t want to commit. These could be system files, editor configuration files, or build artifacts.

git status
On branch main
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .DS_Store
        logs/debug.log
        build/
        node_modules/

Committing these files would unnecessarily bloat the repository and could cause issues for other collaborators.

Solution

1. Create a .gitignore File

Create a file named .gitignore in the root directory of your Git repository.

You can create it using a text editor or a command line tool:

touch .gitignore

2. Add Patterns to .gitignore

Open the .gitignore file and add patterns for the files and directories you want to ignore. Each pattern should be on a new line.

# Ignore macOS system files
.DS_Store

# Ignore log files
logs/
*.log

# Ignore build output directory
build/

# Ignore dependency directories
node_modules/

• #: Lines starting with a hash are comments.
• logs/: Ignores the entire logs directory.
• *.log: Ignores any file with the .log extension (e.g., debug.log, error.log).
• build/: Ignores the build directory.
• node_modules/: Ignores the node_modules directory.

3. Commit the .gitignore File

The .gitignore file itself should be committed to the repository. This ensures that the same ignore rules are applied for all collaborators.

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

Now, when you run git status, the ignored files will no longer appear in the untracked files list.

Ignoring Already Tracked Files

What if you accidentally committed a file that should have been ignored? Simply adding the file to .gitignore won’t make Git stop tracking it.

You first need to tell Git to stop tracking the file using git rm --cached.

For example, to untrack the config.local file:

1. Add config.local to your .gitignore file.
2. Run the command:

   git rm --cached config.local
   

3. Commit the changes:

   git commit -m "Stop tracking config.local"
   

The --cached option removes the file from Git’s tracking, but it remains in your local directory.

Global .gitignore

You can also create a global .gitignore file for all your repositories on your system. This is useful for ignoring files specific to your operating system or editor.

1. Create a file, for example, ~/.gitignore_global.
2. Configure Git to use this file:

   git config --global core.excludesfile ~/.gitignore_global
   

3. Add any global patterns to this file.

Conclusion

Using a .gitignore file is essential for keeping your repository clean and focused on the important source code. It prevents unnecessary files from being committed and shared. Many templates for different programming languages and frameworks are available online to get you started.

Professional Depth Check

For How to Use .gitignore to Exclude Files from Git Tracking, the practical standard is not whether the reader can repeat one instruction once. Treat the topic as a reproducible debugging procedure: verify repository root, branch and remote state, index and working tree, and credential or network boundary before drawing a conclusion. The result should be written as a small decision record, because future readers need to know which fact was observed, which assumption was used, and which condition would change the answer.

Evidence That Makes the Guidance Reliable

Use objective evidence before changing a workflow. Good evidence includes git status, git remote -v, git branch --show-current, and the exact command that failed. If two pieces of evidence conflict, keep the conflict visible instead of smoothing it over. For example, a successful quick fix is still weak evidence if the same input, account, dependency, or device state has not been tested again. A durable article should help the reader distinguish a confirmed fix from a plausible fix.

Review Table

Review Item	What To Confirm	Why It Matters
Scope	The exact case covered by this article	Prevents over-applying the advice
Baseline	The state before any change	Makes rollback and comparison possible
Change	The smallest action taken	Reduces hidden side effects
Result	The observed output after the change	Separates evidence from expectation
Recheck	When to revisit the conclusion	Keeps the post accurate over time

Edge Cases and Failure Modes

The main risks are fixing the symptom while leaving the root cause, and mixing unrelated changes into the same test. When the situation involves production data, personal information, money, health, legal rights, or security recovery, the conservative path is to stop and collect evidence before applying a broad fix. The same title can describe very different cases, so the reader should compare their environment with the assumptions in the post before copying commands or decisions.

Maintenance Standard

Recheck this guidance after dependency, operating-system, or build-tool changes. A useful update does not need to rewrite the entire post; it should confirm whether the examples, links, commands, screenshots, and decision criteria still match current behavior. If the old conclusion remains valid, record the check date. If it changes, explain what changed and why the previous advice is no longer enough.

Related Reading

Continue with these related posts from the same topic area.

• How to Fix “SSL: CERTIFICATE_VERIFY_FAILED” Error in Python on Windows
• How to Fix “Permission denied (publickey)” Error with Git on Windows