When working with Git you will quickly come across several files which are present in the working copy for various reasons but which should not be tracked by Git. The typical examples are logs, compiled binaries or IDE configuration files. Of course, if you don’t add them to the index and letter commit them, they will not appear in the repository.

However, before every commit you will see those files in the output of git status command which not only makes it a bit harder to read but also greatly increases a chance that you add them to the index and commit by mistake. Below is a sample output of git status with such files:

$ git status
On branch master
Changes not staged for commit:

Untracked files:
  (use "git add ..." to include in what will be committed)

        .classpath
        .project
        .settings/
        target/
        faces-config.NavData
        nb-configuration.xml
        (... more files ...)

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

Ignoring files

Luckily, Git makes it very easy to ignore such files so that they will no longer appear in the output of git status and therefore it will be almost impossible to mistakenly add them to the index and commit.

The most common method is to create .gitignore file in the root directory of your working copy, add there several patterns matching the files or directories to ignore (one per line) and commit it so that these rules will be shared across the entire development team.

The pattern may be either a path to the file which should be ignored:

/.classpath

a path to the directory which should be ignored (including all its contents):

/target/

or a shell pattern matching one of the above:

/*config*

The asterisk means any number of any characters as in shell. There is also possibility to specify two consecutive asterisks in a pattern which matches any number of path components. For example:

/**/server-log*

ignores all server-log* files or directories anywhere in the working copy.

Additionally, if the pattern does not contain slash, Git recursively checks and ignores all files present in the working copy and its subdirectories if their name matches specified shell glob.

Per-directory and global excludes

To make things even more complicated each subdirectory of the working copy (not only the root) may contain its own .gitignore file. This directory specific file applies only to this directory and its subdirectories and has higher level of precedence than the ones in the parent directories (including the root directory of the working copy).

Additionally, it is possible to configure global excludes which are shared across all git working copies on a single workstation. The location of the file with them is pointed by core.excludesfile variable:

$ git config --get  core.excludesfile

and can be also set to the custom path if necessary (or empty):

$ git config --global core.excludesfile /home/robert/.gitignore

The global excludes have the lowest level of precedence. They should be used only in rare cases and should never be a replacement for project specific excludes.

Which files to ignore

There are several kinds of files which should be usually ignored:

• IDE configuration files
• build directories
• compiled binaries
• generated files
• build, test or coverage reports
• logs

Of course, the list is not complete and the exact patterns strongly depend on your project and environment.

And if you are tempted to commit IDE configuration files, please know that everybody configures IDE in its own way which will result in a lot of merge conflicts.

Ignored files and the repository contents

Ignoring the file or directory does not mean it is no longer present in the repository or it will be automatically removed from it. The file may be still in the repository if it was stored there before adding appropriate excludes, it was a result of merge with older branch or somebody messed with excludes.

Conclusion

Ability to ignore specific files or directories is quite easy but very useful feature of Git. GitHub’s gitignore repository provides pretty good list of various git-ignore rules for many operating systems, environments and languages which you may use as a good starting point for your own project. And in case of problems you can always refer to git-ignore manual page.