visit
.gitignore
is a file that lets you describe name patterns of what Git should ignore. It supports wildcards, so with few rules, you can catch many files that should be ignored:
# Ignore all files with the exe extension
*.exe
# Ignore dist & converage folders
dist/
converage/
# Nested location
some-folder/another-folder/*.txt
# Complex name pattern
build-config.*.yml
Why is .gitingore
’s name starting with a dot? It’s a UNIX convention for hidden files. So, for example, the ls -l
command will not show it.
The most common is to set up .gitignore
in the root folder of the project. It’s the first place other people will check, and by specifying a nested location, it allows you to control any files across the codebase. You can find it in most serious projects. Here are a few open source examples:
.gitignore
files can be added in on any level of the repository tree. When provided, it will control the files inside it—everything else works like from the root folder. Example for open source:
You can specify a global .gitignore
, and put the patterns that are specific to your environment. For example, you might do this if your code editor creates temporary files in the folder where it’s open, and you don’t want or cannot alter the project’s .gitignore
.
$ git config --global core.excludesfile
You will get the name or your global .gitignore
file, or nothing. In the latter case, you can set the file name yourself. For example, for Linux or macOS, you would probably do something like:
$ git config --global core.excludesfile ~/.gitignore
Then, in that file, you add patterns related to your code editor and operating system. In my case, I would ignore temporary files created by Vim:
*~
*.swp
*.swo
node_modules
is a folder where npm
installs all dependencies. Some people argue it can be tracked as part of the repository, but the most common approach is to ignore it. I recommend ignoring it because:
package.json
and package-lock.json
whenever it’s neededdist
—default output folder in Webpackcoverage
—often used for coverage reports of unit testsDifferent team members often use different code editors. Definitely, you don’t want your configuration leaking to the repository—it could mess up the settings of your colleagues who use the same editor, and it will create noise for everybody else. As editor choice is unrelated to the project, it would make sense to have everybody set the correct ignore pattern on their machine. As you can see in the open source examples above, teams often decide to just add the editor-relater patterns to the project .gitignore
—after all, it’s usually just a few lines at most.
.gitignore
generatorsAs you can see, setting up .gitignore
can get pretty complicated. Luckily, you don’t have to create those files completely on your own!
With it, you can initialize your repository with a .gitignore
related to your project’s needs.
.gitingore