How To Add A Git Ignore File

Saving changes

.gitignore

Git sees every file in your working copy as ane of three things:

tracked - a file which has been previously staged or committed;
untracked - a file which has not been staged or committed; or
ignored - a file which Git has been explicitly told to ignore.

Ignored files are usually build artifacts and machine generated files that can be derived from your repository source or should otherwise not be committed. Some common examples are:

dependency caches, such as the contents of /node_modules or /packages
compiled code, such as .o, .pyc, and .class files
build output directories, such as /bin, /out, or /target
files generated at runtime, such every bit .log, .lock, or .tmp
hidden arrangement files, such as .DS_Store or Thumbs.db
personal IDE config files, such as .idea/workspace.xml

Ignored files are tracked in a special file named .gitignore that is checked in at the root of your repository. At that place is no explicit git ignore command: instead the .gitignore file must exist edited and committed by hand when you lot have new files that you wish to ignore. .gitignore files incorporate patterns that are matched against file names in your repository to determine whether or non they should be ignored.

Ignoring files in Git
- Git ignore patterns
- Shared .gitignore files in your repository
- Personal Git ignore rules
- Global Git ignore rules
- Ignoring a previously committed file
- Committing an ignored file
- Stashing an ignored file
- Debugging .gitignore files

Git ignore patterns

.gitignore uses globbing patterns to match against file names. You can construct your patterns using various symbols:

Pattern	Example matches	Explanation*
`**/logs`	`logs/debug.log` `logs/monday/foo.bar` `build/logs/debug.log`	You can prepend a pattern with a double asterisk to match directories anywhere in the repository.
`**/logs/debug.log`	`logs/debug.log` `build/logs/debug.log` merely not `logs/build/debug.log`	You can as well use a double asterisk to match files based on their proper noun and the proper name of their parent directory.
`*.log`	`debug.log` `foo.log` `.log` `logs/debug.log`	An asterisk is a wildcard that matches zip or more than characters.
`*.log` `!of import.log`	`debug.log` `trace.log` only not `important.log` `logs/important.log`	Prepending an exclamation marker to a pattern negates information technology. If a file matches a pattern, but besides matches a negating pattern defined afterwards in the file, information technology will not exist ignored.
`.log` `!important/.log` `trace.*`	`debug.log` `important/trace.log` but not `of import/debug.log`	Patterns divers after a negating pattern will re-ignore whatsoever previously negated files.
`/debug.log`	`debug.log` merely not `logs/debug.log`	Prepending a slash matches files only in the repository root.
`debug.log`	`debug.log` `logs/debug.log`	By default, patterns friction match files in any directory
`debug?.log`	`debug0.log` `debugg.log` merely not `debug10.log`	A question mark matches exactly one character.
`debug[0-9].log`	`debug0.log` `debug1.log` only non `debug10.log`	Square brackets can also be used to match a single character from a specified range.
`debug[01].log`	`debug0.log` `debug1.log` but not `debug2.log` `debug01.log`	Square brackets match a unmarried character form the specified ready.
`debug[!01].log`	`debug2.log` but non `debug0.log` `debug1.log` `debug01.log`	An exclamation mark can be used to match whatever character except 1 from the specified set up.
`debug[a-z].log`	`debuga.log` `debugb.log` only not `debug1.log`	Ranges tin can be numeric or alphabetic.
`logs`	`logs` `logs/debug.log` `logs/latest/foo.bar` `build/logs` `build/logs/debug.log`	If you don't append a slash, the pattern volition friction match both files and the contents of directories with that name. In the example matches on the left, both directories and files named logs are ignored
logs/	`logs/debug.log` `logs/latest/foo.bar` `build/logs/foo.bar` `build/logs/latest/debug.log`	Appending a slash indicates the pattern is a directory. The entire contents of any directory in the repository matching that name – including all of its files and subdirectories – will be ignored
`logs/` `!logs/important.log`	`logs/debug.log` `logs/important.log`	Look a infinitesimal! Shouldn't `logs/of import.log` be negated in the instance on the left Nope! Due to a performance-related quirk in Git, you can non negate a file that is ignored due to a pattern matching a directory
`logs/**/debug.log`	`logs/debug.log` `logs/mon/debug.log` `logs/monday/pm/debug.log`	A double asterisk matches zero or more directories.
`logs/*day/debug.log`	`logs/monday/debug.log` `logs/tuesday/debug.log` but not `logs/latest/debug.log`	Wildcards can be used in directory names too.
`logs/debug.log`	`logs/debug.log` but not `debug.log` `build/logs/debug.log`	Patterns specifying a file in a particular directory are relative to the repository root. (You can prepend a slash if y'all like, but it doesn't do anything special.)

** these explanations assume your .gitignore file is in the superlative level directory of your repository, as is the convention. If your repository has multiple .gitignore files, just mentally supplant "repository root" with "directory containing the .gitignore file" (and consider unifying them, for the sanity of your team).*

In improver to these characters, you lot can employ # to include comments in your .gitignore file:

You lot can use \ to escape .gitignore pattern characters if you have files or directories containing them:

              # ignore the file literally named foo[01].txt
foo\[01\].txt

Git ignore rules are unremarkably defined in a .gitignore file at the root of your repository. All the same, y'all can cull to define multiple .gitignore files in dissimilar directories in your repository. Each pattern in a item .gitignore file is tested relative to the directory containing that file. Nevertheless the convention, and simplest arroyo, is to ascertain a single .gitignore file in the root. As your .gitignore file is checked in, it is versioned similar whatsoever other file in your repository and shared with your teammates when y'all push button. Typically yous should simply include patterns in .gitignore that volition benefit other users of the repository.

Personal Git ignore rules

You can as well define personal ignore patterns for a detail repository in a special file at .git/info/exclude. These are non versioned, and not distributed with your repository, so information technology'south an advisable place to include patterns that will probable only benefit you. For example if you have a custom logging setup, or special development tools that produce files in your repository's working directory, yous could consider calculation them to .git/info/exclude to forestall them from beingness accidentally committed to your repository.

Global Git ignore rules

In addition, you tin can define global Git ignore patterns for all repositories on your local arrangement by setting the Git core.excludesFile property. You'll have to create this file yourself. If you're unsure where to put your global .gitignore file, your dwelling house directory isn't a bad choice (and makes it piece of cake to find later). Once you've created the file, you'll demand to configure its location with git config:

              $ touch ~/.gitignore
$ git config --global core.excludesFile ~/.gitignore

Yous should be careful what patterns y'all cull to globally ignore, as different file types are relevant for different projects. Special operating system files (due east.one thousand. .DS_Store and thumbs.db) or temporary files created past some developer tools are typical candidates for ignoring globally.

Ignoring a previously committed file

If you desire to ignore a file that you've committed in the past, you lot'll need to delete the file from your repository so add together a .gitignore rule for information technology. Using the --cached option with git rm ways that the file will exist deleted from your repository, simply volition remain in your working directory equally an ignored file.

              $ repeat debug.log >> .gitignore  $ git rm --cached debug.log
rm 'debug.log'
                  $ git commit -1000 "Offset ignoring debug.log"

You tin omit the --buried option if you want to delete the file from both the repository and your local file organization.

Committing an ignored file

It is possible to force an ignored file to exist committed to the repository using the -f (or --forcefulness) option with git add:

              $ cat .gitignore
*.log  $ git add together -f debug.log
                  $ git commit -m "Forcefulness adding debug.log"

You lot might consider doing this if you have a general pattern (like *.log) defined, but you desire to commit a specific file. However a better solution is to define an exception to the general rule:

              $ echo !debug.log >> .gitignore  $ cat .gitignore
*.log
!debug.log
                  $ git add debug.log
                  $ git commit -m "Calculation debug.log"

This arroyo is more obvious, and less confusing, for your teammates.

Stashing an ignored file

git stash is a powerful Git feature for temporarily shelving and reverting local changes, allowing you to re-utilise them afterwards on. As you'd expect, by default git stash ignores ignored files and simply stashes changes to files that are tracked by Git. However, you tin invoke git stash with the --all pick to stash changes to ignored and untracked files too.

Debugging .gitignore files

If y'all take complicated .gitignore patterns, or patterns spread over multiple .gitignore files, it can be difficult to rail down why a detail file is being ignored. You can use the git bank check-ignore command with the -v (or --verbose) option to determine which design is causing a particular file to be ignored:

              $ git bank check-ignore -five debug.log
.gitignore:3:*.log  debug.log

The output shows:

              <file containing the pattern> : <line number of the pattern> : <blueprint>    <file name>

Y'all can laissez passer multiple file names to git bank check-ignore if you lot like, and the names themselves don't even have to correspond to files that exist in your repository.