The .gitignore file is a plain text document that tells Git which files or folders it should completely ignore from version control.
When working with Git, sometimes we have files that we don’t want to save at all. For example, temporary files, build folders, error logs, or local configurations from your code editor.
Committing all of this to the repository clutters your history, takes up unnecessary space, and, worse, can pose a huge security risk (for example, if you accidentally commit private keys or passwords).
To avoid these headaches, the .gitignore file exists, which contains rules. If a file matches a rule, Git will ignore it completely.
It’s a very particular file, as it has no name, only the extension.
Rule Syntax
Writing rules in this .gitignore is very easy. Each line is a pattern.
# This is a comment
secret_file.txt # Ignore this specific file
*.log # Ignore all files ending in .log
temp/ # Ignore the entire temp folder (and its contents)
!important.log # The '!' sign is an exception: do NOT ignore this file
The most common patterns you will use are:
- *: Wildcard for any string of characters.
- /: At the end indicates a directory.
- !: Negates the previous rule (useful for “ignore everything except this”).
What Should You Always Ignore?
Although it depends on your programming language, there are four categories of files that almost never should go into Git:
Downloaded Dependencies
If you program in Node.js (node_modules), Python (venv) or PHP (vendor), those folders weigh hundreds of megabytes and can be regenerated with a command (npm install). Never commit them.
Compiled or Binary Files
If you use C++, Java or C#, don’t commit the .exe, .o, .class files or the bin/ and obj/ folders. The source code is what matters; the binary is generated from it.
System or IDE Files
Your team doesn’t need to know you use Mac (.DS_Store) or that you have a specific VS Code configuration (.vscode/). That’s personal to your machine.
Credentials and Secrets 🛑
Files like .env, config.json with passwords or API keys. If you commit this to a public repository, consider yourself hacked.
Git is not a place to store secrets. Even in private repositories, keys should not be in the code. Use environment variables.
The “It’s Too Late” Problem
If a file is already in Git’s database (you already committed it), adding it to the ignore file does nothing. Git will continue tracking its changes. That is,
You create a file my_text.txt.
You do git add and git commit.
You realize the mistake and add it to .gitignore.
You keep working.
Surprise! Git is still tracking my_text.txt.
The .gitignore only works with files that are Untracked (that Git doesn’t know about).
How to Fix It?
You have to tell Git to “forget” the file, but without deleting it from your hard drive (because you need it to work).
We use the rm command with the --cached option:
git rm --cached my_text.txt
- This deletes the file from the Staging Area (and from the next commit), but leaves it intact in your Working Directory.
- Now that it’s Untracked again, Git will read the
.gitignore, see the rule, and ignore it forever.
If you have accidentally committed a private file, this does not protect you. If you have pushed to a remote, anyone can see the file in the history even if you delete it.
