In such case, you can add a shell glob pattern to match files that you want to have ignored by Git to one of the gitignore files, one pattern per line:

Some commands, such as git clean, also allow us to specify ignore patterns from a command line.

When deciding whether to ignore a path, Git checks all those sources in the order specified on preceding list, with the last matching pattern deciding the outcome. The .gitignore files are checked in order, starting from the top directory of the project down to the directory of files to be examined.

To make gitignore files more readable you can use blank lines to separate groups of files (a blank line matches no files). You can also describe patterns or groups of patterns with comments; a line starting with # serves as one (to ignore a pattern beginning with the hash character, #, escape the first hash character with a backslash , for example, #*#). Trailing spaces (at the end of the line) are ignored unless escaped with a backslash .

Each line in the gitignore file specifies a Unix glob pattern, a shell wildcard. The * wildcard matches zero or more characters (any string), while the ? wildcard matches any single character. You can also use character classes with brackets [...]. Take for example the following list of patterns:

*.[oa]
*~

Here the first line tells Git to ignore all files with the .a or .o extension—archive (for example, a static library) and object files that may be the products of compiling your code. The second line tells Git to ignore all files ending with a tilde, ~; this is used by many Unix text editors to mark temporary backup files.

If the pattern does not contain a slash /, which is a directory (path component) separator, Git treats it as a shell glob and checks file name or directory name for a match, starting at appropriate depth, for example the .gitignore file location, or the top level of the repository. The exception is patterns ending with slash /—which is used to have the pattern matched against directories only—but otherwise the trailing slash is removed. A leading slash matches the beginning of the path name. This means the following:

You can also negate a pattern by prefixing it with an exclamation mark !; any matching file excluded by the earlier rule is then included (non-ignored) again. For example to ignore all generated HTML files, but include one generated by hand, you can put the following in the gitignore file:

# ignore html files, generated from AsciiDoc sources
*.html
# except for the files below which are generated by hand
!welcome.html

Note however that for performance reasons Git doesn't go into excluded directories, and (up till Git 2.7) this meant that you cannot re-include a file if a parent directory is excluded. This means that to ignore everything except for the subdirectory, you need to write the following:

# exclude everything except directory t0001/bin
/*
!/t0001
/t0001/*
!/t0001/bin

To match a pattern beginning with !, escape it with a backslash—for example, !important!.md to match !important!.md.

Now that we know how to mark files as intentionally untracked (ignored), there is the question of which files (or classes of files) should be marked as such. Another issue is where, in which of the three gitignore files, should we add a pattern for ignoring specific types of file?

First, you should never track automatically generated files (usually generated by the build system of a project). If you add them to the repository, there is a high chance that they will get out of sync with their source. Besides, they are not necessary, as you can always re-generate them. The only possible exception is generated files where the source changes rarely, and generating them requires extra tools that developers might not have (if the source changes more often, you can use an orphan branch to store these generated files, and refresh this branch only at release time).

Those are the files that all developers will want to ignore. Therefore they should go into a tracked .gitignore file. The list of patterns will be version-controlled and distributed to other developers via a clone. You can find a collection of useful .gitignore templates for different programming languages at https://github.com/github/gitignore.

Second, there are temporary files and by-products specific to one user's toolchain; those should usually not be shared with other developers. If the pattern is specific to both the repository and the user, for example, auxiliary files that live inside the repository but are specific to the workflow of a user (for example, to the IDE used for the project), it should go into the per-clone $GIT_DIR/info/exclude file.

Patterns which the user wants to ignore in all situations, not specific to the repository (or to the project), should generally go into a file specified by the core.excludesFile config variable, set in the per-user (global) config file ~/.gitconfig (or ~/.config/git/config). This is usually by default ~/.config/git/ignore.

This is the place where you can put patterns matching the backup or temporary files generated by your editor or IDE of choice.

You can list untracked ignored files with the --ignored option to the status command:

$ git status --ignored
On branch master
Ignored files:
  (use "git add -f <file>..." to include in what will be committed)

        rand.c~

no changes added to commit (use "git add" and/or "git commit -a")

$ git status --short --branch --ignored
## master
!! rand.c~

You could instead use the dry-run option of cleaning ignored files: git clean -Xnd, or the low-level (plumbing) command git ls-files:

$ git ls-files --others --ignored --exclude-standard
rand.c~

The latter command can also be used to list tracked files that match ignore patterns. Having such files might mean that some files need to be un-tracked (perhaps because what was once a source file is now generated), or that ignore patterns are too broad. As Git uses the existence of a file in the staging area (cache) to know which files to track, this can be done with the following command:

$ git ls-files --cached --ignored --exclude-standard

You might have files in the repository that are changed, but rarely committed. These can be various local configuration files that are edited to match the local setup, but should never be committed upstream. This can be a file containing the proposed name for a new release, to be committed when tagging the next released version.

You would want to keep such files in the dirty state most of the time, but you would like Git not to tell you about their changes all the time, in case you miss other changes because you are used to ignore such messages.

Git can be configured to skip checking the worktree (to assume that it is always up to date), and to use instead the staged version of the file, by setting the aptly named skip-worktree flag for a file. For this you would need to use the low-level git update-index command, the plumbing equivalent of the user-facing git add porcelain (you can check file status and flags with `git ls-files`):

$ git update-index --skip-worktree GIT-VERSION-NAME
$ git ls-files -v
S GIT-VERSION-NAME
H Makefile

Note however that this elision of worktree also includes the git stash command; to stash away your changes and make the working directory clean, you need to disable this flag (at least temporarily). To make Git again look at the working directory version, and start tracking changes to the file, use the following command:

$ git update-index --no-assume-unchanged GIT-VERSION-NAME