The use cases of global Git excludes file

Git excludes file, often referred to as “global .gitignore,” is a file that defines global ignore rules for tracking files across all local Git repositories.

We can use it to add some extra files in the tracked folders to enhance our local experience without affecting other users:

• Custom entry points

  • Using different tools to run things. For example, using just files instead of the default project’s task runner.

  • Configuring additional tasks for local workflow.

• Custom environment

  • Adding a mise.toml file to automatically install correct runtime dependencies even if the rest of the team prefers other tools.

  • Avoiding the clutter of environment-specific files, like .DS_Store files on MacOS.

• Custom editor configuration

  • .vscode/, .idea/, and other editor-specific configs.

• Personal documentation

  • Personal README and other doc files directly where you need them.

• Custom tests and configuration

  • Working with custom and ad hoc tests by having our own test files. For example, using *.http files with REST Client extension to test API endpoints during development.

  • Using custom test configuration for a test runner.

• Temporary files and folders

  • Being able to store temporary exports for testing import/export functionality.

  • Storing uncommitted, personal test data, e.g., images, directly in the project folder.

  • Scratch files for custom scripts.

• Sensitive files

  • Keys, passwords, and so on.

While having custom files in the project folder can be awesome, it is good to mention that Git ignore rules should still be placed in the project’s .gitignore file whenever it makes sense:

• When it is expected that developers will want to adjust some behavior, provide the proper rules right away. For example, a dev.sh script with entry points can automatically source untracked pre- and post- user scripts so that the behavior can be customized.

• It is still better to make sure common OS and editor files are ignored in the project itself to prevent accidents.

• The project’s .gitignore file should always cover any project files that affect everyone, including build, dependency, and log directories, generated docs or test output, cache files, and so on.

When a project’s entry points or documentation are not sufficient, it almost always makes sense to try to improve the experience for everybody in the project first; custom files in the project folder are the last resort, in my opinion.

---

The rules in Git excludes file follow the same concepts and syntax as standard .gitignore files, they just act as a “parent” for all of them.

The default location of the excludes file will depend on your environment. On Linux, it will be ~/.config/git/ignore. It can also be set to a custom location:

# check if custom location of excludes file is set
git config --global core.excludesFile

# set custom excludes file location
git config --global core.excludesFile ~/.globalgitignore

If you happen to use a custom location, I recommend not naming the file .gitignore if you want to keep it under version control. In any case, it is a good idea to track the file in your dotfiles directory.

---

Some useful things to know:

• If you happen to work in a Git repository and you want to commit an ignored file, you can always start tracking the file by invoking git add with —force or -f flag (git add -f ignoredfile.txt). This is useful for cases where you cannot or don’t want to modify the ignore rules for some reason. The file will be tracked from that point on in the repository despite the rules.

• The use cases of the global Git excludes file can be similar to using repository-specific setting .git/info/exclude inside each Git repository. In both cases the ignore rules are personal and not shared with other users, but a big advantage of Git excludes file is the ability to be easily tracked in your own repository. .git/info/exclude could be useful for quick, ad hoc ignore rules.

---

And that’s it.

— Petr