As a git user, you will undoubtedly have come across "git ignore", but do you also know about "git exclude"? This handy feature, judging from my Fediverse notifications, seems not as well-known as I thought.

In this article, I will explain what git exclude is, why it is different from git ignore, and when to use which.

Note: To avoid jokes in the realm of "say git one more time, mother-effer", I will refer to these features as "exclude" and "ignore" in the rest of the article.

So, what is it?

Exclude, like ignore, is a way of telling git not to track a file in a repository.

The two features are nearly identical in use and even share the same page in the official gitignore documentation.

So, if you understand the rules of one, you will get the other for free.

Note: I am Dutch, so the word "free" makes me all giddy on the inside.

What is the difference between exclude and ignore?

So if "exclude" and "ignore" are syntactically identical, how do they differ?

The two main differences between these features are:

1. File location(s): files are stored in different places.
2. File tracking: git does not track the exclude file.

While you can scatter gitignore files throughout your repository with the enthusiasm of a chef who adds "just a pinch of salt" to the recipe, there is only one exclude file.

The exclude file is located in the .git directory, which most editors hide from you. More precisely, you will find it here:

my-repository/.git/info/exclude

Actually, you might find it there, as there is a high probability that the directory and file do not exist after cloning the repository. Luckily, you can create them just like any other item.

Yes, this file may not exist by default, as git does not track it; it is an ignore file only for you, and only in that checkout of the repository.

2025-09-04 note: Some people report having the file post-clone, others (like me) do not have it.

So if you were to clone one repository three times on the same machine, then add the same file to each of them, and exclude that file in only one of the three repos, you would still see it in the other two.

Why is this useful again?

The usefulness of the exclude file is clearly not in its visibility, but it is powerful nonetheless.

Exclude is particularly handy when you want to keep personal, non-standard files in a repository that is not yours, and where you cannot update its ignore files willy-nilly.

Some examples I have used it for:

1. Personal scripts and script files (e.g., Makefile, Justfile, Taskfile).
2. Temporary code and more of that random experimental stuff.
3. A Django management command named zzz_marijke, for when a regular Python module does not cut it.
4. A Docker Compose override file, before someone finally added that one to the project's main ignore file (where it belongs).

What about global gitignore files?

The Fediverse reminded me not once, but twice, about global git ignore files, so it is only fair to mention these as well.

The global gitignore file is a single file that lives somewhere in your filesystem, and that is designated as "the" file in your global git configuration.

I use the global ignore only for machine-specific items that I do not want to exclude separately in each repository. This usually comes down to editor- or extension-specific files that are too niche for a regular ignore file.

These days, I prefer using a starter template from gitignore.org in my project over expanding my global file. Still, it has its use, and I would recommend setting one up if needed.

Word of advice: Be careful about globally ignoring files. It would not be the first time someone accidentally added a file to the repo that someone else forgot to add to the project ignore file, as they already had it in their global one.

Want to set up such a file for yourself? Check out: "Setting up a global .gitignore file" by Sebastian De Deyne. (Hat-tip to Benjamin Balder Bach for this link.)

When to use which?

To recap, we looked at three ways to omit files from git repositories:

1. The git repository's exclude file;
2. Arbitrary project git ignore files;
3. A global git ignore file.

You can use a combination of all three for all projects, and determine which of the three is most suitable for the file you want to omit from the repository.

I would advise that you focus on a project-level ignore file first, for two reasons:

1. It applies to everyone who works on the project, preventing accidental check-ins of unwanted files.
2. Unlike the other two, you will see these files in your code editor when you open the project directory.

As for the exclude file and global ignore file, that is more up to preference.

I typically put temporary project-specific files in exclude, and code editor-related files in global.

Once I start excluding the same file in multiple repositories, it is time to move to the global ignore file.

I also highly recommend looking up starter templates for language-specific ignore files; these usually already contain many entries you and your team might need in the future.

Wrap-up

I get surprised every time I mention the existence of git exclude to people, only to be met with a "today I learned" response.

Then again, there is so much to git, and I know there is a lot I do not know, and maybe never will.

Still, git exclude is one of those features you do want to know, and I hope you will enjoy this new tool in your kit.

(Pun intended?)

My git workflow is partially command-line-based and partially UI-driven, with visual support for the exclude file. Hence, I have no issues with the lack of visibility of the exclusion file.

However, per a Fediverse discussion earlier today, one of the respondents wrote an article about his workaround to make exclude more visible: "Using direnv to add a personal .gitignore file to repos" by Josh Thomas.

Have fun excluding!

Disclaimer: Exclude files, not humans, please.

Changelog

2025-09-05:

• Replaced "does not exist" with "may not exist" and added a note regarding the possible absence of an exclude file post-clone.