Как найти файл gitignore

Git рассматривает каждый файл в вашей рабочей копии как файл одного из трех нижеуказанных типов.

  1. Отслеживаемый файл — файл, который был предварительно проиндексирован или зафиксирован в коммите.
  2. Неотслеживаемый файл — файл, который не был проиндексирован или зафиксирован в коммите.
  3. Игнорируемый файл — файл, явным образом помеченный для Git как файл, который необходимо игнорировать.

Игнорируемые файлы — это, как правило, артефакты сборки и файлы, генерируемые машиной из исходных файлов в вашем репозитории, либо файлы, которые по какой-либо иной причине не должны попадать в коммиты. Вот некоторые распространенные примеры таких файлов:

  • кэши зависимостей, например содержимое /node_modules или /packages;
  • скомпилированный код, например файлы .o, .pyc и .class ;
  • каталоги для выходных данных сборки, например /bin, /out или /target;
  • файлы, сгенерированные во время выполнения, например .log, .lock или .tmp;
  • скрытые системные файлы, например .DS_Store или Thumbs.db;
  • личные файлы конфигурации IDE, например .idea/workspace.xml.

Игнорируемые файлы отслеживаются в специальном файле .gitignore, который регистрируется в корневом каталоге репозитория. В Git нет специальной команды для указания игнорируемых файлов: вместо этого необходимо вручную отредактировать файл .gitignore, чтобы указать в нем новые файлы, которые должны быть проигнорированы. Файлы .gitignore содержат шаблоны, которые сопоставляются с именами файлов в репозитории для определения необходимости игнорировать эти файлы.

  • Игнорирование файлов в Git
    • Шаблоны игнорирования в Git
    • Общие файлы .gitignore в вашем репозитории
    • Персональные правила игнорирования в Git
    • Глобальные правила игнорирования в Git
    • Игнорирование ранее закоммиченного файла
    • Коммит игнорируемого файла
    • Скрытие изменений в игнорируем файле
    • Отладка файлов .gitignore

Шаблоны игнорирования в Git

Для сопоставления с именами файлов в .gitignore используются шаблоны подстановки. С помощью различных символов можно создавать собственные шаблоны.

Шаблон Примеры соответствия Пояснение*
**/logs logs/debug.log
logs/monday/foo.bar
build/logs/debug.log
Добавьте в начало шаблона две звездочки, чтобы сопоставлять каталоги в любом месте репозитория.
**/logs/debug.log logs/debug.log
build/logs/debug.log
но не
logs/build/debug.log
Две звездочки можно также использовать для сопоставления файлов на основе их имени и имени родительского каталога.
*.log debug.log
foo.log
.log
logs/debug.log
Одна звездочка — это подстановочный знак, который может соответствовать как нескольким символам, так и ни одному.
*.log
!important.log
debug.log
trace.log
но не
important.log
logs/important.log
Добавление восклицательного знака в начало шаблона отменяет действие шаблона. Если файл соответствует некоему шаблону, но при этом также соответствует отменяющему шаблону, указанному после, такой файл не будет игнорироваться.
*.log
!important/*.log
trace.*
debug.log
important/trace.log
но не
important/debug.log
Шаблоны, указанные после отменяющего шаблона, снова будут помечать файлы как игнорируемые, даже если ранее игнорирование этих файлов было отменено.
/debug.log debug.log
но не
logs/debug.log
Косая черта перед именем файла соответствует файлу в корневом каталоге репозитория.
debug.log debug.log
logs/debug.log
По умолчанию шаблоны соответствуют файлам, находящимся в любом каталоге
debug?.log debug0.log
debugg.log
но не
debug10.log
Знак вопроса соответствует строго одному символу.
debug[0-9].log debug0.log
debug1.log
но не
debug10.log
Квадратные скобки можно также использовать для указания соответствия одному символу из заданного диапазона.
debug[01].log debug0.log
debug1.log
но не
debug2.log
debug01.log
Квадратные скобки соответствуют одному символу из указанного набора.
debug[!01].log debug2.log
но не
debug0.log
debug1.log
debug01.log
Восклицательный знак можно использовать для указания соответствия любому символу, кроме символов из указанного набора.
debug[a-z].log debuga.log
debugb.log
но не
debug1.log
Диапазоны могут быть цифровыми или буквенными.
logs logs
logs/debug.log
logs/latest/foo.bar
build/logs
build/logs/debug.log
Без косой черты в конце этот шаблон будет соответствовать и файлам, и содержимому каталогов с таким именем. В примере соответствия слева игнорируются и каталоги, и файлы с именем logs
logs/ logs/debug.log
logs/latest/foo.bar
build/logs/foo.bar
build/logs/latest/debug.log
Косая черта в конце шаблона означает каталог. Все содержимое любого каталога репозитория, соответствующего этому имени (включая все его файлы и подкаталоги), будет игнорироваться
logs/
!logs/important.log
logs/debug.log
logs/important.log
Минуточку! Разве файл logs/important.log из примера слева не должен быть исключен нз списка игнорируемых?

Нет! Из-за странностей Git, связанных с производительностью, вы не можете отменить игнорирование файла, которое задано шаблоном соответствия каталогу

logs/**/debug.log logs/debug.log
logs/monday/debug.log
logs/monday/pm/debug.log
Две звездочки соответствуют множеству каталогов или ни одному.
logs/*day/debug.log logs/monday/debug.log
logs/tuesday/debug.log
but not
logs/latest/debug.log
Подстановочные символы можно использовать и в именах каталогов.
logs/debug.log logs/debug.log
но не
debug.log
build/logs/debug.log
Шаблоны, указывающие на файл в определенном каталоге, задаются относительно корневого каталога репозитория. (При желании можно добавить в начало косую черту, но она ни на что особо не повлияет.)

Две звездочки (**) означают, что ваш файл .gitignore находится в каталоге верхнего уровня вашего репозитория, как указано в соглашении. Если в репозитории несколько файлов .gitignore, просто мысленно поменяйте слова «корень репозитория» на «каталог, содержащий файл .gitignore» (и подумайте об объединении этих файлов, чтобы упростить работу для своей команды)*.

Помимо указанных символов, можно использовать символ #, чтобы добавить в файл .gitignore комментарии:

Если у вас есть файлы или каталоги, в имени которых содержатся спецсимволы шаблонов, для экранирования этих спецсимволов в .gitignore можно использовать обратную косую черту ():

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

Обычно правила игнорирования Git задаются в файле .gitignore в корневом каталоге репозитория. Тем не менее вы можете определить несколько файлов .gitignore в разных каталогах репозитория. Каждый шаблон из конкретного файла .gitignore проверяется относительно каталога, в котором содержится этот файл. Однако проще всего (и этот подход рекомендуется в качестве общего соглашения) определить один файл .gitignore в корневом каталоге. После регистрации файла .gitignore для него, как и для любого другого файла в репозитории, включается контроль версий, а после публикации с помощью команды push он становится доступен остальным участникам команды. В файл .gitignore, как правило, включаются только те шаблоны, которые будут полезны другим пользователям репозитория.

Персональные правила игнорирования в Git

В специальном файле, который находится в папке .git/info/exclude, можно определить персональные шаблоны игнорирования для конкретного репозитория. Этот файл не имеет контроля версий и не распространяется вместе с репозиторием, поэтому он хорошо подходит для указания шаблонов, которые будут полезны только вам. Например, если у вас есть пользовательские настройки для ведения журналов или специальные инструменты разработки, которые создают файлы в рабочем каталоге вашего репозитория, вы можете добавить их в .git/info/exclude, чтобы они случайно не попали в коммит в вашем репозитории.

Глобальные правила игнорирования в Git

Кроме того, для всех репозиториев в локальной системе можно определить глобальные шаблоны игнорирования Git, настроив параметр конфигурации Git core.excludesFile . Этот файл нужно создать самостоятельно. Если вы не знаете, куда поместить глобальный файл .gitignore, расположите его в домашнем каталоге (потом его будет легче найти). После создания этого файла необходимо настроить его местоположение с помощью команды git config:

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

Будьте внимательны при указании глобальных шаблонов игнорирования, поскольку для разных проектов актуальны различные типы файлов. Типичные кандидаты на глобальное игнорирование — это специальные файлы операционной системы (например, .DS_Store и thumbs.db) или временные файлы, создаваемые некоторыми инструментами разработки.

Игнорирование ранее закоммиченного файла

Чтобы игнорировать файл, для которого ранее был сделан коммит, необходимо удалить этот файл из репозитория, а затем добавить для него правило в .gitignore . Используйте команду git rm с параметром --cached, чтобы удалить этот файл из репозитория, но оставить его в рабочем каталоге как игнорируемый файл.

$ echo debug.log >> .gitignore

  $ git rm --cached debug.log
rm 'debug.log'

  $ git commit -m "Start ignoring debug.log"

Опустите опцию --cached, чтобы удалить файл как из репозитория, так и из локальной файловой системы.

Коммит игнорируемого файла

Можно принудительно сделать коммит игнорируемого файла в репозиторий с помощью команды git add с параметром -f (или --force):

$ cat .gitignore
*.log

  $ git add -f debug.log

  $ git commit -m "Force adding debug.log"

Этот способ хорош, если у вас задан общий шаблон (например, *.log), но вы хотите сделать коммит определенного файла. Однако еще лучше в этом случае задать исключение из общего правила:

$ echo !debug.log >> .gitignore

  $ cat .gitignore
*.log
!debug.log

  $ git add debug.log

  $ git commit -m "Adding debug.log"

Этот подход более прозрачен и понятен, если вы работаете в команде.

Скрытие изменений в игнорируем файле

Команда git stash — это мощная функция системы Git, позволяющая временно отложить и отменить локальные изменения, а позже применить их повторно. По умолчанию команда git stash ожидаемо не обрабатывает игнорируемые файлы и создает отложенные изменения только для тех файлов, которые отслеживаются Git. Тем не менее вы можете вызвать команду git stash с параметром —all, чтобы создать отложенные изменения также для игнорируемых и неотслеживаемых файлов.

Отладка файлов .gitignore

Если шаблоны .gitignore сложны или разбиты на множество файлов .gitignore, бывает непросто отследить, почему игнорируется определенный файл. Используйте команду git check-ignore с параметром -v (или --verbose), чтобы определить, какой шаблон приводит к игнорированию конкретного файла:

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

Вывод показывает:

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

При желании команде git check-ignore можно передать несколько имен файлов, причем сами имена могут даже не соответствовать файлам, существующим в вашем репозитории.

You can configure Git to ignore files you don’t want to check in to GitHub.

Configuring ignored files for a single repository

You can create a .gitignore file in your repository’s root directory to tell Git which files and directories to ignore when you make a commit.
To share the ignore rules with other users who clone the repository, commit the .gitignore file in to your repository.

GitHub maintains an official list of recommended .gitignore files for many popular operating systems, environments, and languages in the github/gitignore public repository. You can also use gitignore.io to create a .gitignore file for your operating system, programming language, or IDE. For more information, see «github/gitignore» and the «gitignore.io» site.

  1. Open TerminalTerminalGit Bash.

  2. Navigate to the location of your Git repository.

  3. Create a .gitignore file for your repository.

    $ touch .gitignore

    If the command succeeds, there will be no output.

For an example .gitignore file, see «Some common .gitignore configurations» in the Octocat repository.

If you want to ignore a file that is already checked in, you must untrack the file before you add a rule to ignore it. From your terminal, untrack the file.

$ git rm --cached FILENAME

Configuring ignored files for all repositories on your computer

You can also create a global .gitignore file to define a list of rules for ignoring files in every Git repository on your computer. For example, you might create the file at ~/.gitignore_global and add some rules to it.

  1. Open TerminalTerminalGit Bash.
  2. Configure Git to use the exclude file ~/.gitignore_global for all Git repositories.
    $ git config --global core.excludesfile ~/.gitignore_global

Excluding local files without creating a .gitignore file

If you don’t want to create a .gitignore file to share with others, you can create rules that are not committed with the repository. You can use this technique for locally-generated files that you don’t expect other users to generate, such as files created by your editor.

Use your favorite text editor to open the file called .git/info/exclude within the root of your Git repository. Any rule you add here will not be checked in, and will only ignore files for your local repository.

  1. Open TerminalTerminalGit Bash.
  2. Navigate to the location of your Git repository.
  3. Using your favorite text editor, open the file .git/info/exclude.

Further Reading

  • Ignoring files in the Git documentation
  • .gitignore in the Git documentation
  • A collection of useful .gitignore templates in the github/gitignore repository
  • gitignore.io site

NAME

gitignore — Specifies intentionally untracked files to ignore

SYNOPSIS

$XDG_CONFIG_HOME/git/ignore, $GIT_DIR/info/exclude, .gitignore

DESCRIPTION

A gitignore file specifies intentionally untracked files that
Git should ignore.
Files already tracked by Git are not affected; see the NOTES
below for details.

Each line in a gitignore 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 .gitignore file in the same directory
    as the path, or in any parent directory (up to the top-level of the working
    tree), with patterns in the higher level files being overridden by those in
    lower level files down to the directory containing the file. These patterns
    match relative to the location of the .gitignore file. A project normally
    includes such .gitignore files in its repository, containing patterns for
    files generated as part of the project build.

  • Patterns read from $GIT_DIR/info/exclude.

  • Patterns read from the file specified by the configuration
    variable core.excludesFile.

Which file to place a pattern in depends on how the pattern is meant to
be used.

  • 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 .gitignore file.

  • Patterns which are
    specific to a particular repository but which do not need to be shared
    with other related repositories (e.g., auxiliary files that live inside
    the repository but are specific to one user’s workflow) should go into
    the $GIT_DIR/info/exclude file.

  • 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.excludesFile in the user’s ~/.gitconfig. Its default value is
    $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or
    empty, $HOME/.config/git/ignore is used instead.

The underlying Git plumbing tools, such as
git ls-files and git read-tree, read
gitignore patterns specified by command-line options, or from
files specified by command-line options. Higher-level Git
tools, such as git status and git add,
use patterns from the sources specified above.

PATTERN FORMAT

  • A blank line matches no files, so it can serve as a separator
    for readability.

  • A line starting with # serves as a comment.
    Put a backslash (««) in front of the first hash for patterns
    that begin with a hash.

  • Trailing spaces are ignored unless they are quoted with backslash
    «).

  • An optional prefix «!» which negates the pattern; any
    matching file excluded by a previous pattern will become
    included again. It is not possible to re-include a file if a parent
    directory of that file is excluded. Git doesn’t list excluded
    directories for performance reasons, so any patterns on contained
    files have no effect, no matter where they are defined.
    Put a backslash (««) in front of the first «!» for patterns
    that begin with a literal «!«, for example, «!important!.txt«.

  • The slash / is used as the directory separator. Separators may
    occur at the beginning, middle or end of the .gitignore search pattern.

  • If there is a separator at the beginning or middle (or both) of the
    pattern, then the pattern is relative to the directory level of the
    particular .gitignore file itself. Otherwise the pattern may also
    match at any level below the .gitignore level.

  • If there is a separator at the end of the pattern then the pattern
    will only match directories, otherwise the pattern can match both
    files and directories.

  • For example, a pattern doc/frotz/ matches doc/frotz directory,
    but not a/doc/frotz directory; however frotz/ matches frotz
    and a/frotz that is a directory (all paths are relative from
    the .gitignore file).

  • An asterisk «*» matches anything except a slash.
    The character «?» matches any one character except «/«.
    The range notation, e.g. [a-zA-Z], can be used to match
    one of the characters in a range. See fnmatch(3) and the
    FNM_PATHNAME flag for a more detailed description.

Two consecutive asterisks («**«) in patterns matched against
full pathname may have special meaning:

  • A leading «**» followed by a slash means match in all
    directories. For example, «**/foo» matches file or directory
    «foo» anywhere, the same as pattern «foo«. «**/foo/bar»
    matches file or directory «bar» anywhere that is directly
    under directory «foo«.

  • A trailing «/**» matches everything inside. For example,
    «abc/**» matches all files inside directory «abc«, relative
    to the location of the .gitignore file, with infinite depth.

  • A slash followed by two consecutive asterisks then a slash
    matches zero or more directories. For example, «a/**/b»
    matches «a/b«, «a/x/b«, «a/x/y/b» and so on.

  • Other consecutive asterisks are considered regular asterisks and
    will match according to the previous rules.

CONFIGURATION

The optional configuration variable core.excludesFile indicates a path to a
file containing patterns of file names to exclude, similar to
$GIT_DIR/info/exclude. Patterns in the exclude file are used in addition to
those in $GIT_DIR/info/exclude.

NOTES

The purpose of gitignore files is to ensure that certain files
not tracked by Git remain untracked.

To stop tracking a file that is currently tracked, use
git rm —cached.

Git does not follow symbolic links when accessing a .gitignore file in
the working tree. This keeps behavior consistent when the file is
accessed from the index or a tree versus from the filesystem.

EXAMPLES

  • The pattern hello.* matches any file or directory
    whose name begins with hello.. If one wants to restrict
    this only to the directory and not in its subdirectories,
    one can prepend the pattern with a slash, i.e. /hello.*;
    the pattern now matches hello.txt, hello.c but not
    a/hello.java.

  • The pattern foo/ will match a directory foo and
    paths underneath it, but will not match a regular file
    or a symbolic link foo (this is consistent with the
    way how pathspec works in general in Git)

  • The pattern doc/frotz and /doc/frotz have the same effect
    in any .gitignore file. In other words, a leading slash
    is not relevant if there is already a middle slash in
    the pattern.

  • The pattern «foo/*», matches «foo/test.json»
    (a regular file), «foo/bar» (a directory), but it does not match
    «foo/bar/hello.c» (a regular file), as the asterisk in the
    pattern does not match «bar/hello.c» which has a slash in it.

    $ git status
    [...]
    # Untracked files:
    [...]
    #       Documentation/foo.html
    #       Documentation/gitignore.html
    #       file.o
    #       lib.a
    #       src/internal.o
    [...]
    $ cat .git/info/exclude
    # ignore objects and archives, anywhere in the tree.
    *.[oa]
    $ cat Documentation/.gitignore
    # ignore generated html files,
    *.html
    # except foo.html which is maintained by hand
    !foo.html
    $ git status
    [...]
    # Untracked files:
    [...]
    #       Documentation/foo.html
    [...]

Another example:

    $ cat .gitignore
    vmlinux*
    $ ls arch/foo/kernel/vm*
    arch/foo/kernel/vmlinux.lds.S
    $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore

The second .gitignore prevents Git from ignoring
arch/foo/kernel/vmlinux.lds.S.

Example to exclude everything except a specific directory foo/bar
(note the /* — without the slash, the wildcard would also exclude
everything within foo/bar):

    $ cat .gitignore
    # exclude everything except directory foo/bar
    /*
    !/foo
    /foo/*
    !/foo/bar

SEE ALSO

Does the .gitignore file belong in the .git folder structure somewhere or in the main source files?

Russia Must Remove Putin's user avatar

asked Apr 18, 2011 at 3:14

mishaF's user avatar

1

Put .gitignore in the working directory. It doesn’t work if you put it in the .git (repository) directory.

$ ls -1d .git*
.git
.gitignore

answered Sep 30, 2013 at 15:58

jmulho's user avatar

jmulhojmulho

5,1881 gold badge12 silver badges2 bronze badges

4

As the other answers stated, you can place .gitignore within any directory in a Git repository. However, if you need to have a private version of .gitignore, you can add the rules to .git/info/exclude file.

answered Apr 18, 2011 at 3:38

Alan Haggai Alavi's user avatar

Alan Haggai AlaviAlan Haggai Alavi

72.4k19 gold badges101 silver badges127 bronze badges

3

You can place .gitignore in any directory in git.

It’s commonly used as a placeholder file in folders, since folders aren’t usually tracked by git.

answered Apr 18, 2011 at 3:16

philipk's user avatar

philipkphilipk

1,47316 silver badges22 bronze badges

2

In the simple case, a repository might have a single .gitignore file in its root directory, which applies recursively to the entire repository. However, it is also possible to have additional .gitignore files in subdirectories. The rules in these nested .gitignore files apply only to the files under the directory where they are located. The Linux kernel source repository has 206 .gitignore files.

— this is what i read from progit.pdf(version 2), P32

Steven's user avatar

Steven

1,6032 gold badges15 silver badges30 bronze badges

answered Jul 11, 2020 at 0:48

C Lei's user avatar

C LeiC Lei

4094 silver badges5 bronze badges

1

If you want to do it globally, you can use the default path git will search for. Just place it inside a file named «ignore» in the path ~/.config/git

(so full path for your file is: ~/.config/git/ignore)

Daniel Holmes's user avatar

answered Jun 4, 2014 at 10:13

Liran Brimer's user avatar

Liran BrimerLiran Brimer

3,3781 gold badge28 silver badges23 bronze badges

Root directory is fine for placing the .gitignore file.

Don’t forget to use git rm --cached FILENAME to add files to .gitignore if you have created the gitignore file after you committed the repo with a file you want ignored. See github docs. I found this out when I created a .env file, then committed it, then tried it to ignore it by creating a .gitignore file.

answered Jan 21, 2021 at 23:27

Mr. J's user avatar

Mr. JMr. J

1,4022 gold badges17 silver badges40 bronze badges

You may also find a global .gitignore directly at the ~ path if you haven’t created it in your folder project.
This file is taken into account by all your .git projects.

answered Apr 11, 2018 at 12:18

XLE_22's user avatar

XLE_22XLE_22

5,0393 gold badges20 silver badges71 bronze badges

2

From the official documentation:

Git checks gitignore patterns from multiple sources, with the following order of precedence (the last matching pattern decides the outcome):

  1. Patterns read from the command line for those commands that support them.

  2. Patterns read from a .gitignore file in the same directory as the path, or in any parent directory (up to the top-level of the working tree), with patterns in the higher level files being overridden by those in lower level files down to the directory containing the file.

  3. Patterns read from $GIT_DIR/info/exclude.

  4. Patterns read from the file specified by the configuration variable core.excludesFile.

answered Nov 3, 2022 at 11:38

Luca Fagioli's user avatar

Luca FagioliLuca Fagioli

12.5k5 gold badges58 silver badges57 bronze badges

Also, if you create a new account on Github you will have the option to add .gitignore and it will be setup automatically on the right/standard location of your working place. You don’t have to add anything in there at the begin, just alter the contents any time you want.

answered Oct 24, 2016 at 8:42

Thielicious's user avatar

ThieliciousThielicious

4,0522 gold badges25 silver badges35 bronze badges

.gitignore File – How to Ignore Files and Folders in Git

Git is a popular version control system. It is how developers can collaborate and work together on projects.

Git allows you to track the changes you make to your project over time. On top of that, it lets you revert to a previous version if you want to undo a change.

The way Git works is that you stage files in a project with the git add command and then commit them with the git commit command.

When working on a project as part of a team, there will be times when you don’t want to share some files or parts of the project with others.

In other words, you don’t want to include or commit those specific files to the main version of the project. This is why you may not want to use the period . with the git add command as this stages every single file in the current Git directory.

When you use the git commit command, every single file gets committed – this also includes files that do not need to be or shouldn’t be.

You may instead want Git to ignore specific files, but there is no git ignore command for that purpose.

So, how do you tell Git to ignore and not track specific files? With a .gitignore file.

In this article, you will learn what a .gitignore file is, how to create one, and how to use it to ignore files and folders. You will also see how you can ignore a previously committed file.

Here is what we will cover:

  1. What is a .gitignore file?
    1. How to create a .gitignore file
    2. What to Include in a .gitignore file?
  2. How to ignore a file and folder in Git
    1. How to ignore a previously committed file

What Is a .gitignore File? What Is a .gitignore File Used For?

Each of the files in any current working Git repository is either:

  • tracked – these are all the files or directories Git knows about. These are the files and directories newly staged (added with git add) and committed (committed with git commit) to the main repo.
  • untracked – these are any new files or directories created in the working directory but that have not yet been staged (or added using the git add command).
  • ignored – these are all the files or directories that Git knows to completely exclude, ignore, and not be aware of in the Git repository. Essentially, this is a way to tell Git which untracked files should remain untracked and never get committed.

All ignored files get stored in a .gitignore file.

A .gitignore file is a plain text file that contains a list of all the specified files and folders from the project that Git should ignore and not track.

Inside .gitignore, you can tell Git to ignore only a single file or a single folder by mentioning the name or pattern of that specific file or folder. You can also tell Git to ignore multiple files or folders using the same method.

How to Create a .gitignore File

Typically, a .gitignore file gets placed in the root directory of the repository. The root directory is also known as the parent and the current working directory. The root folder contains all the files and other folders that make up the project.

That said, you can place it in any folder in the repository. You can even have multiple .gitignore files, for that matter.

To create a .gitignore file on a Unix-based system such as macOS or Linux using the command line, open the terminal application (such as Terminal.app on macOS). Then, navigate to the root folder that contains the project using the cd command and enter the following command to create a .gitignore file for your directory:

touch .gitignore

Files with a dot (.) preceding their name are hidden by default.

Hidden files are not visible when using the ls command alone. To view all files – including hidden ones – from the command line, use the -a flag with the ls command like so:

ls -a

What to Include in a .gitignore File

The types of files you should consider adding to a .gitignore file are any files that do not need to get committed.

You may not want to commit them for security reasons or because they are local to you and therefore unnecessary for other developers working on the same project as you.

Some of these may include:

  • Operating System files. Each Operating System (such as macOS, Windows, and Linux) generates system-specific hidden files that other developers don’t need to use since their system also generates them. For example, on macOS, Finder generates a .DS_Store file that includes user preferences for the appearance and display of folders, such as the size and position of icons.
  • Configuration files generated by applications such as code editors and IDEs (IDE stands for Integrated Development Environment). These files are custom to you, your configurations, and your preferences settings.
  • Files that get automatically generated from the programming language or framework you are using in your project and compiled code-specific files, such as .o files.
  • Folders generated by package managers, such as npm’s node_modules folder. This is a folder used for saving and tracking the dependencies for each package you install locally.
  • Files that contain sensitive data and personal information. Some examples of such files are files with your credentials (username and password) and files with environment variables like .env files (.env files contain API keys that need to remain secure and private).
  • Runtime files, such as .log files. They provide information on the Operating System’s usage activities and errors, as well as a history of events that have taken place within the OS.

How to Ignore a File and Folder in Git

If you want to ignore only one specific file, you need to provide the full path to the file from the root of the project.

For example, if you want to ignore a text.txt file located in the root directory, you would do the following:

/text.txt

And if you wanted to ignore a text.txt file located in a test directory at the root directory, you would do the following:

/test/text.txt

You could also write the above like so:

test/text.txt

If you want to ignore all files with a specific name, you need to write the literal name of the file.

For example, if you wanted to ignore any text.txt files, you would add the following to .gitignore:

text.txt

In this case, you don’t need to provide the full path to a specific file. This pattern will ignore all files with that particular name that are located anywhere in the project.

To ignore an entire directory with all its contents, you need to include the name of the directory with the slash / at the end:

test/

This command will ignore any directory (including other files and other sub-directories inside the directory) named test located anywhere in your project.

Something to note is that if you write the name of a file alone or the name of the directory alone without the slash /, then this pattern will match both any files or directories with that name:

# matches any files and directories with the name test
test

What if you want to ignore any files or directories that start with a specific word?

Say that you want to ignore all files and directories that have a name starting with img. To do this, you would need to specify the name you want to ignore followed by the * wildcard selector like so:

img*

This command will ignore all files and directories that have a name starting with img.

But what if you want to ignore any files or directories that end with a specific word?

If you wanted to ignore all files that end with a specific file extension, you would need to use the * wildcard selector followed by the file extension you want to ignore.

For example, if you wanted to ignore all markdown files that end with a .md file extension, you would add the following to your .gitignore file:

*.md

This pattern will match any file ending with the .md extension located anywhere in the project.

Earlier, you saw how to ignore all files ending with a specific suffix. What happens when you want to make an exception, and there is one file with that suffix that you don’t want to ignore?

Say you added the following to your .gitignore file:

.md

This pattern ignores all files ending in .md, but you don’t want Git to ignore a README.md file.

To do this, you would need to use the negating pattern with an exclamation mark, !, to negate a file that would otherwise be ignored:

# ignores all .md files
.md

# does not ignore the README.md file
!README.md

With both of those patterns in the .gitignore file, all files ending in .md get ignored except for the README.md file.

Something to keep in mind is that this pattern will not work if you ignore an entire directory.

Say that you ignore all test directories:

test/

Say that inside a test folder, you have a file, example.md, that you don’t want to ignore.

You cannot negate a file inside an ignored directory like so:

# ignore all directories with the name test
test/

# trying to negate a file inside an ignored directory won't work
!test/example.md

How to Ignore a Previously Committed File

It’s a best practice to create a .gitignore file with all the files and the different file patterns you want to ignore when you create a new repository – before committing it.

Git can only ignore untracked files that haven’t yet been committed to the repository.

What happens when you have already committed a file in the past and wish you hadn’t?

Say you accidentally committed a .env file that stores environment variables.

You first need to update the .gitignore file to include the .env file:

# add .env file to .gitignore
echo ".env" >> .gitignore

Now, you will need to tell Git not to track this file by removing it from the index:

git rm --cached .env

The git rm command, along with the --cached option, deletes the file from the repository but does not delete the actual file. This means the file remains on your local system and in your working directory as an ignored file.

A git status will show that the file is no longer in the repository, and entering the ls command will show that the file exists on your local file system.

If you want to delete the file from the repository and your local system, omit the --cached option.

Next, add the .gitignore to the staging area using the git add command:

git add .gitignore

Finally, commit the .gitignore file using the git commit command:

git commit -m "update ignored files"

Conclusion

And there you have it – you now know the basics of ignoring files and folders in Git.

Hopefully, you found this article helpful.

To learn more about Git, check out the following free resources:

  • Git and GitHub for Beginners — Crash Course
  • Git for Professionals Tutorial — Tools & Concepts for Mastering Version Control with Git
  • Advanced Git Tutorial — Interactive Rebase, Cherry-Picking, Reflog, Submodules and more

Thank you for reading and happy coding :)



Learn to code for free. freeCodeCamp’s open source curriculum has helped more than 40,000 people get jobs as developers. Get started

Понравилась статья? Поделить с друзьями:
  • Как найти описанную окружность около треугольника формула
  • Телевизор показывает красным цветом как исправить
  • Вальгус как исправить ребенку упражнения
  • Если неверно оприходован документ в закрытом периоде как исправить
  • Как составить булевой запрос