This is an old revision of the document!
Overview
How to identify untracked files that Git should intentionally ignore; files already tracked by Git are not affected.
Some links:
Four levels of ignoring files
Each line in a gitignore/exclude file specifies a pattern. When deciding whether to ignore a path, Git normally checks gitignore patterns from multiple sources, with the following order of precedence, from highest to lowest (within one level of precedence, the last matching pattern decides the outcome):
- Patterns read from the command line for those commands that support them,
- Patterns read from a
.gitignorefile in the same directory as the path, or in any parent directory, with patterns in the higher level files (up to the toplevel of the work tree) being overridden by those in lower level files down to the directory containing the file. These patterns match relative to the location of the.gitignorefile. A project normally includes such.gitignorefiles in its repository, containing patterns for files generated as part of the project build, - Patterns read from (repository-specific)
$GIT_DIR/info/exclude, - Patterns read from the file specified by the configuration variable
core.excludesFile(possibly~/.my_ignorefile).
Rationale for different levels of gitignore files
- Patterns which should be version-controlled and distributed to other repositories via clone (i.e., files that all developers will want to ignore) should go into a
.gitignorefile that comes with the repository. - Patterns which are both specific to a particular repository and specific to an individual user’s workflow should go into the
$GIT_DIR/info/excludefile for that repository. - Patterns which a user wants Git to ignore in all situations (e.g., backup or temporary files generated by the user’s editor of choice) generally go into a file specified by
core.excludesFilein the user’s~/.gitconfig.
Debugging gitignore files
$ man git-check-ignore