DEV Community

Cover image for Complete Guide to the `.gitignore` File
Adrián Bailador
Adrián Bailador

Posted on

Complete Guide to the `.gitignore` File

Introduction

The .gitignore file is an essential tool in any Git repository. It allows you to specify which files or directories should not be tracked by Git, helping to keep the repository clean and free of unnecessary files.

Creating a .gitignore File

Creating a .gitignore file is as simple as creating a new text file in the root of your repository with the name .gitignore.

Tools for .gitignore

There are several tools and online resources that can help you generate an appropriate .gitignore file for your project. Some of them are:

What Should I Ignore?

Generally, you should ignore files that are not necessary for the operation of your project or that can be generated from the source code. Some common examples are:

  • Local configuration files
  • Build directories
  • Binary and executable files
  • Logs and data files
  • Downloaded dependencies (like node_modules in Node.js projects)

How to Ignore Different Files and Directories

To ignore specific files or directories, simply add their path to the .gitignore file. For example:

# Ignore the config.json file
config.json

# Ignore all .log files in the logs directory
logs/*.log

# Ignore the entire build directory
build/
Enter fullscreen mode Exit fullscreen mode

Using the * Character

The * character in a .gitignore file is used as a wildcard that can match any string of characters. For example, *.log will ignore all files ending in .log.

Checking the .gitignore File

To check if your .gitignore file is working correctly, you can make a change to a file that should be ignored and then run git status. If the file does not appear in the list of changes, then your .gitignore file is working correctly.

Forgetting to Add a File to .gitignore

If you forget to add a file to .gitignore and it has been previously tracked by Git, you will need to remove it from the repository with:

git rm --cached <file>
Enter fullscreen mode Exit fullscreen mode

Then add it to .gitignore and commit the changes:

echo <file> >> .gitignore
git add .gitignore
git commit -m "Add <file> to .gitignore"
Enter fullscreen mode Exit fullscreen mode

Reverting a File that is Already in .gitignore

If you have ignored a file in .gitignore but then decide you want to track it, you can do so by removing the corresponding entry from the .gitignore file. Then, you can add the file to the repository with git add <file> and commit the changes.

Matching Patterns in .gitignore

Matching patterns in .gitignore allow you to specify which files to ignore. Some examples are:

  • *.log: Ignores all files ending in .log.
  • !/important.log: Does not ignore the important.log file.
  • debug/: Ignores all files in the debug directory.
  • **/debug/*: Ignores all files in any directory named debug.

Negative Patterns in .gitignore

Negative patterns in .gitignore allow you to specify exceptions to the ignore rules. They are indicated with a ! at the beginning. For example, if you want to ignore all .log files except important.log, you can do it like this:

*.log
!/important.log
Enter fullscreen mode Exit fullscreen mode

Ignoring Only Some Files Within a Directory

If you want to ignore only some files within a directory, you can specify them directly in the .gitignore file. For example, if you want to ignore only .txt files in the docs directory, you can do it like this:

docs/*.txt
Enter fullscreen mode Exit fullscreen mode

Ignoring Files in a Specific Branch

Git does not allow ignoring files in a specific branch directly through the .gitignore file. However, you can create different .gitignore files in different branches. Note that if you merge these branches, you will have to resolve conflicts in the .gitignore file.

Excluding an Entire Directory

To exclude an entire directory, simply add the directory name followed by a / to the .gitignore file. For example, to exclude the entire node_modules directory, you can do it like this:

node_modules/
Enter fullscreen mode Exit fullscreen mode

Examples of .gitignore for Common Technologies

.NET

bin/
obj/
*.user
*.suo
*.rsuser
*.vscode/
Enter fullscreen mode Exit fullscreen mode

Angular

/dist
/node_modules
/.env
/.idea
/.vscode
Enter fullscreen mode Exit fullscreen mode

React

/node_modules
/.env
/build
/coverage
.vscode/
.idea/
Enter fullscreen mode Exit fullscreen mode

Python

__pycache__/
*.py[cod]
*.pyo
.env
.venv
.mypy_cache/
.pytest_cache/
Enter fullscreen mode Exit fullscreen mode

Java

*.class
*.jar
*.war
*.ear
target/
Enter fullscreen mode Exit fullscreen mode

Node.js

node_modules/
npm-debug.log
yarn-error.log
Enter fullscreen mode Exit fullscreen mode

Ordering and Organizing .gitignore

Keeping the .gitignore file ordered and organized, especially in large projects, is crucial. Grouping rules by file type or directory makes it easier to read and maintain.

Integration Tools

There are tools that integrate with Git and can automatically generate or manage the .gitignore file, such as some Visual Studio Code extensions and plugins for popular IDEs.

Behavior in Subdirectories

The .gitignore file in a subdirectory applies only to files in that subdirectory and its subdirectories. This allows for specific rules for different parts of the project.

Versioning the .gitignore File

It is important to version and share the .gitignore file with the development team to ensure that everyone works with the same ignore rules.

Advanced Usage Example

Provide an example of advanced usage, such as ignoring all files except one in a directory:

# Ignore all files in logs except important.log
logs/*
!logs/important.log
Enter fullscreen mode Exit fullscreen mode

Possible Confusions and Common Mistakes

List some common errors when using .gitignore, such as forgetting to add the / at the end of a directory or not updating the .gitignore file after significant changes to the project structure.

Including Locally Generated Files

Locally generated files, such as editor configuration files (.vscode/, .idea/) and environment files (.env), should generally be ignored to avoid conflicts between developers using different local configurations.

Comments in .gitignore

Comments in .gitignore can be made using the # character at the beginning of a line. Comments are useful for explaining the purpose of certain ignore rules.

Ignoring File Types Across the Repository

To ignore a file type across the repository, you can use *.log to ignore all .log files anywhere in the repository.

Forcing Tracking of Ignored Files

Sometimes, you may want to force Git to track a file that is normally ignored. This can be done with git add -f <file>.

Checking Ignored Files

You can use the git check-ignore utility to check which rule in the .gitignore file is causing a specific file to be ignored.

Global .gitignore Files

Git also allows for a global .gitignore file to ignore certain files across all repositories on a machine. This can be useful for ignoring, for example, OS-specific or text editor-specific files.

Ignoring Files without Including them in .gitignore

You can use the .git/info/exclude file, which allows you to ignore files similar to .gitignore, but without including the ignore rules in the repository.

Additional Resources and Readings

Provide links to additional resources and documentations:

Conclusion

The .gitignore file is an indispensable tool for managing which files should be ignored by Git, ensuring that only necessary files are tracked and versioned. By mastering the use of .gitignore, you can keep your repository clean and avoid common issues stemming from unnecessary or environment-specific files. Taking advantage of available tools and resources, such as .gitignore generators and templates, will help you create an effective and appropriate .gitignore file for your project. Remember to always version this file and share it with your team to maintain consistency in ignore rules.

Top comments (1)

Collapse
 
akbaran profile image
akbaran

I came for one answer, and got it. Found a whole lot more information I can use in the future as I grow in skill & scope. Thank you Adrián!