How to add a folder to the .gitignore
Maybe my Googling skills are lacking but this seems like a question that should give me back thousands of hits and yet, I can’t find a straight answer.
I do constant pushes to github to share with a remote developer. We both have npm and bower installed. No need to push these huge folders to github all the time. My node_modules are ignored. But I can’t seem to get gitignore to ignore my bower_components folder
I’m not too savvy on cmd, I barely scratch the surface so if you ar going to suggest that, please don’t assume I know what you are talking about. Otherwise if it is as easy as adding it to the file itself using an IDE, well, I did that and no cigar. Here is my .gtignore file for your review
Файл gitignore — примеры и документация
Мы конечно могли бы вручную добавлять нужные файлы в репозиторий, например так:
Однако это было бы очень трудоемко. Гораздо проще использовать команду:
Которая добавит все файлы в каталоге проекта.
Но что если нам не нужны абсолютно все файлы, а есть файлы например в каталоге /cache или /images или /runtime проекта, которые генерируются в процессе работы. Они не должны быть добавлены в репозиторий.
Тут нам и нужен .gitignore. Вам нужно его самим создать и разместить в корне проекта либо нужной подпапке.
Где должен находиться этот файл
Файл может находиться в корне проекта или любом подкаталоге.
Либо можно задать глобальный файл gitignore, таким образом:
Таким образом вы сможете записать в глобальный файл
/.gitignore_global настройки, общие для всех ваших проектов. В нем могут храниться например файлы для игнорирования, которые специфичны для вашей IDE, и по этому не логично добавлять их в репозиторий. Однако файлы, которые специфичны для конкретного проекта, обязательно нужно добавлять в .gitignore самого проекта.
Примеры содержимого .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 уже добавлены в репозиторий
Обратите внимание, что если файлы уже добавлены в git репозиторий, то добавление их в .gitignore не удалит эти файлы. Изменения в них будут продолжать отслеживаться и входить в коммиты, несмотря на то, что они есть в .gitignore .
Нам придется вручную их удалить из репозитория.
Очень удобная команда bash, которая удалит из git репозитория те файлы, которые содержатся в файлах .gitignore :
То же самое для Powershell
При выполнении этой команды, файлы останутся у вас на диске, однако из репозитория они будут удалены.
Либо можно удалять файлы вручную, таким образом:
Либо если нам нужно удалить целую директорию из git, то воспользуемся следующей командой:
Либо так мы могли бы удалить все файлы с расширением .log в папке log:
Параметр —cached означает, что файлы будут удалены только из раздела «проиндексированных файлов». На диске (рабочем каталоге) они останутся нетронутыми.
Как понять, почему игнорируется конкретный файл
Запустите команду вместо path/to/file следует указать путь к файлу.
В итоге мы получим ответ, в котором содержится конкретная строка .gitignore, благодаря которой данный файл игнорируется.
Как добавить папку в гитигнор
- 2.34.1 → 2.37.3 no changes
- 2.34.0 11/15/21
- 2.33.1 → 2.33.4 no changes
- 2.33.0 08/16/21
- 2.32.1 → 2.32.3 no changes
- 2.32.0 06/06/21
- 2.22.2 → 2.31.4 no changes
- 2.22.1 08/11/19
- 2.22.0 06/07/19
- 2.20.1 → 2.21.4 no changes
- 2.20.0 12/09/18
- 2.19.1 → 2.19.6 no changes
- 2.19.0 09/10/18
Check your version of git by running
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.
Git
Игнорирование файлов и папок
В этом разделе показано, как избежать добавления нежелательных файлов (или изменений файлов) в репозитории Git. Существует несколько способов (глобальный или локальный .gitignore , .git/exclude , git update-index —assume-unchanged и git update-index —skip-tree ), но имейте в виду, что Git управляет контентом , что означает: игнорирование фактически игнорирует содержимое папки (то есть файлы). По умолчанию пустая папка будет проигнорирована, так как она не может быть добавлена в любом случае.
Игнорирование файлов и каталогов с помощью файла .gitignore
Вы можете заставить Git игнорировать определенные файлы и каталоги, то есть исключить их от отслеживания Git — путем создания одного или нескольких файлов .gitignore в вашем репозитории.
В проектах программного обеспечения .gitignore обычно содержит список файлов и / или каталогов, которые генерируются во время процесса сборки или во время выполнения. Записи в файле .gitignore могут включать имена или пути, указывающие на:
- временные ресурсы, например, кэши, файлы журналов, скомпилированный код и т. д.
- файлы локальной конфигурации, которые не должны использоваться совместно с другими разработчиками
- файлы, содержащие секретную информацию, такие как пароли входа, ключи и учетные данные
При создании в каталоге верхнего уровня правила будут применяться рекурсивно ко всем файлам и подкаталогам во всем репозитории. При создании в подкаталоге правила будут применяться к этому конкретному каталогу и его подкаталогам.
Когда файл или каталог игнорируются, это не будет:
- отслеживается Git
- сообщается командами, такими как git status или git diff
- с такими командами, как git add -A
В необычном случае, когда вам нужно игнорировать отслеживаемые файлы, следует соблюдать особую осторожность. См .: Игнорировать файлы, которые уже были переданы в репозиторий Git .
Примеры
Вот некоторые общие примеры правил в файле .gitignore , основанные на шаблонах файлов glob :
Большинство файлов .gitignore являются стандартными для разных языков, поэтому для начала работы здесь приведены образцы файлов .gitignore перечисленных на языке, из которого можно клонировать или копировать / вносить изменения в ваш проект. Кроме того, для нового проекта вы можете автоматически генерировать стартовый файл с помощью онлайн-инструмента .
Другие формы .gitignore
Файлы .gitignore предназначены для передачи как часть репозитория. Если вы хотите игнорировать определенные файлы без соблюдения правил игнорирования, вот несколько вариантов:
- Отредактируйте файл .git/info/exclude (используя тот же синтаксис, что и .gitignore ). Правила будут глобальными в объеме хранилища;
- Настройте глобальный файл gitignore, который будет применять правила игнорирования ко всем вашим локальным репозиториям:
Кроме того, вы можете игнорировать локальные изменения в отслеживаемых файлах без изменения глобальной конфигурации git с помощью:
- git update-index —skip-worktree [<file>. ] : для небольших локальных изменений
- git update-index —assume-unchanged [<file>. ] : для производства готовые, не изменяющиеся файлы вверх по течению
Очистка игнорируемых файлов
Вы можете использовать git clean -X для очистки игнорируемых файлов:
Примечание: -X (caps) очищает только игнорируемые файлы. Используйте -x (без ограничений), чтобы удалить ненужные файлы.
Дополнительную информацию см. В руководстве Git .
Исключения в файле .gitignore
Если вы игнорируете файлы с помощью шаблона, но имеете исключения, префикс восклицательного знака (!) К исключению. Например:
В приведенном выше примере Git игнорирует все файлы с расширением .txt за исключением файлов с именем important.txt .
Если файл находится в папке проигнорировано, вы не можете повторно включить его так легко:
В этом примере все .txt-файлы в папке будут игнорироваться.
Правильный способ заключается в повторном включении самой папки в отдельной строке, а затем игнорировать все файлы в folder на * , наконец, повторно включить *.txt в folder , как показано ниже:
Примечание . Для имен файлов, начинающихся с восклицательного знака, добавьте два восклицательных знака или выйдите с символом \ :
Глобальный файл .gitignore
Чтобы Git игнорировал определенные файлы во всех репозиториях, вы можете создать глобальный .gitignore со следующей командой в своем терминале или командной строке:
Теперь Git будет использовать это в дополнение к собственному файлу .gitignore каждого репозитория. Правила для этого:
- Если локальный файл .gitignore явно содержит файл, а глобальный .gitignore игнорирует его, локальный .gitignore имеет приоритет (файл будет включен)
- Если репозиторий клонирован на нескольких компьютерах, глобальный .gigignore должен быть загружен на всех машинах или, по крайней мере, включать его, поскольку проигнорированные файлы будут .gitignore на репо, тогда как ПК с глобальным .gitignore не будет обновлять его , Вот почему специфический .gitignore — лучшая идея, чем глобальная, если проект обрабатывается командой
Этот файл является хорошим местом для игнорирования игнорирования .DS_Store платформы, компьютера или пользователя, например OSX .DS_Store , Windows Thumbs.db или Vim *.ext
и *.ext.swp игнорирует, если вы не хотите сохранять их в репозитории , Поэтому один член команды, работающий над OS X, может добавить все .DS_STORE и _MACOSX (что фактически бесполезно), в то время как другой член команды в Windows может игнорировать все thumbs.bd
Игнорировать файлы, которые уже были переданы в репозиторий Git
Если вы уже добавили файл в свой репозиторий Git и теперь хотите прекратить его отслеживать (чтобы он не присутствовал в будущих коммитах), вы можете удалить его из индекса:
Это приведет к удалению файла из репозитория и предотвращению отслеживания дальнейших изменений Git. Параметр —cached гарантирует, что файл не будет физически удален.
Обратите внимание, что ранее добавленное содержимое файла по-прежнему будет отображаться через историю Git.
Имейте в виду, что если кто-то еще вытащит из репозитория после удаления файла из индекса, их копия будет физически удалена .
Вы можете заставить Git притвориться, что версия рабочего каталога файла обновлена и вместо этого прочитала индексную версию (таким образом, игнорируя изменения в ней) с битом « skip worktree »:
На этот бит не влияет запись, безопасность контента по-прежнему является первоочередной задачей. Вы никогда не потеряете свои драгоценные игнорируемые изменения; с другой стороны, этот бит конфликтует с тиснением: чтобы удалить этот бит, используйте
Иногда ошибочно рекомендуется лгать Гиту и предположить, что файл остается неизменным, не изучая его. Он выглядит на первый взгляд как игнорирование любых дальнейших изменений в файле, не удаляя его из его индекса:
Это заставит git игнорировать любые изменения, внесенные в файл (имейте в виду, что если вы поместите какие-либо изменения в этот файл или вы его запишете, ваши проигнорированные изменения будут потеряны )
Если вы хотите, чтобы git снова «заботился» об этом файле, выполните следующую команду:
Проверка игнорирования файла
Команда git check-ignore сообщает о файлах, игнорируемых Git.
Вы можете передавать имена файлов в командной строке, а git check-ignore будет отображать имена файлов, которые игнорируются. Например:
Здесь только * .o файлы определены в .gitignore, поэтому Readme.md не указан в выводе git check-ignore .
Если вы хотите увидеть строку, в которой .gitignore отвечает за игнорирование файла, добавьте -v в команду git check-ignore:
Начиная с Git 1.7.6, вы также можете использовать git status —ignored , чтобы увидеть проигнорированные файлы. Дополнительную информацию об этом можно найти в официальной документации или в разделе «Поиск файлов, игнорируемых с помощью .gitignore» .
Игнорирование файлов в подпапках (несколько файлов gitignore)
Предположим, что у вас есть структура репозитория:
output.log в каталоге примеров действителен и требуется, чтобы проект собирал понимание, в то время как один под src/ создается во время отладки и не должен находиться в истории или части хранилища.
Существует два способа игнорировать этот файл. Вы можете поместить абсолютный путь в файл .gitignore в корень рабочего каталога:
Кроме того, вы можете создать файл .gitignore каталоге src/ и проигнорировать файл, относящийся к этому .gitignore :
Игнорирование файла в любом каталоге
Чтобы игнорировать файл foo.txt в любом каталоге, вы должны просто написать его имя:
Если вы хотите игнорировать файл только в части дерева, вы можете указать подкаталоги определенного каталога с ** pattern:
Или вы можете создать файл .gitignore каталоге bar/ . Эквивалентным предыдущему примеру будет создание файла bar/.gitignore с этим содержимым:
Игнорировать файлы локально без правил игнорирования
.gitignore игнорирует файлы локально, но предназначен для .gitignore к репозиторию и совместно с другими участниками и пользователями. Вы можете установить глобальный .gitignore , но тогда все ваши репозитории будут делиться этими настройками.
Если вы хотите игнорировать определенные файлы в репозитории локально и не создавать файловую часть какого-либо репозитория, отредактируйте файл .git/info/exclude внутри своего репозитория.
Заполненные шаблоны .gitignore
Если вы не знаете, какие правила перечислять в вашем файле .gitignore или просто хотите добавить общепринятые исключения в свой проект, вы можете выбрать или сгенерировать файл .gitignore :
- https://www.gitignore.io/
- https://github.com/github/gitignore
Многие хостинговые сервисы, такие как GitHub и BitBucket, предлагают возможность генерации файлов .gitignore на основе языков программирования и IDE, которые вы можете использовать:
Игнорирование последующих изменений в файле (без его удаления)
Иногда вы хотите иметь файл, хранящийся в Git, но игнорировать последующие изменения.
Скажите Git игнорировать изменения в файле или каталоге с помощью update-index :
Вышеупомянутая команда дает указание Git предположить, my-file.txt не был изменен, а не проверять или сообщать об изменениях. Файл все еще присутствует в репозитории.
Это может быть полезно для предоставления значений по умолчанию и разрешения переопределения локальной среды, например:
Игнорирование только части файла [заглушки]
Иногда вам может потребоваться локальные изменения в файле, который вы не хотите комментировать или публиковать. В идеале локальные настройки должны быть сконцентрированы в отдельном файле, который может быть помещен в .gitignore , но иногда в качестве краткосрочного решения может быть полезно иметь что-то локальное в зарегистрированном файле.
Вы можете сделать Git «unsee» эти строки, используя чистый фильтр. Они даже не появятся в разностях.
Предположим, что это фрагмент файла file1.c :
Вы не хотите публиковать NOCOMMIT .
Создайте фильтр «nocommit», добавив его в конфигурационный файл Git, например .git/config :
Добавьте (или создайте) это в .git/info/attributes или .gitmodules :
И ваши линии NOCOMMIT скрыты от Git.
- Использование чистого фильтра замедляет обработку файлов, особенно в Windows.
- Пропущенная строка может исчезнуть из файла, когда Git обновляет ее. Его можно противодействовать фильтром размытия, но это сложнее.
- Не тестировалось в Windows
Игнорирование изменений в отслеживаемых файлах. [Заглушка]
.gitignore и .git/info/exclude работают только для файлов без следа.
Чтобы установить флаг игнорирования в отслеживаемом файле, используйте команду update-index :
Чтобы восстановить это, используйте:
Вы можете добавить этот фрагмент в свою глобальную конфигурацию git, чтобы иметь более удобную git hidden git hide , git unhide и git hidden команды:
Вы также можете использовать опцию —assume-неизменной с функцией update-index
Если вы хотите снова просмотреть этот файл для изменений, используйте
Когда задан флаг -измеренный неизмененный, пользователь обещает не изменять файл и позволяет Git предположить, что рабочий файл дерева соответствует тому, что записано в index.Git не удастся, если ему необходимо изменить этот файл в индексе например, при слиянии в фиксации; таким образом, в случае, если файл с необработанной версией изменен вверх по потоку, вам придется обрабатывать ситуацию вручную. В этом случае основное внимание уделяется производительности.
Хотя флаг -skip-worktree полезен, когда вы даете указание git не касаться определенного файла из-за того, что файл будет изменен локально, и вы не захотите случайно зафиксировать изменения (т. Е. Файл конфигурации / свойств, сконфигурированный для определенного среда). Skip-worktree имеет приоритет над принятием-неизменным, когда оба установлены.
Очистить уже зафиксированные файлы, но включенные в .gitignore
Иногда случается, что файл отслеживается git, но в более поздний момент времени был добавлен в .gitignore, чтобы остановить его отслеживание. Очень распространенный сценарий забыть очистить такие файлы до его добавления в .gitignore. В этом случае старый файл все равно будет висящим в репозитории.
Чтобы устранить эту проблему, можно было выполнить «сухое» удаление всего в репозитории, а затем повторное добавление всех файлов обратно. Пока у вас нет ожидающих изменений и —cached параметр —cached , эта команда достаточно безопасна для запуска:
Создать пустую папку
Невозможно добавить и зафиксировать пустую папку в Git из-за того, что Git управляет файлами и прикрепляет к ним свой каталог, который сглаживает и фиксирует скорость. Чтобы обойти это, существует два метода:
Метод первый: .gitkeep
Один хак, чтобы обойти это, — использовать файл .gitkeep для регистрации папки для Git. Для этого просто создайте требуемый каталог и добавьте файл .gitkeep в папку. Этот файл пуст и не служит никакой другой цели, кроме как просто зарегистрировать эту папку. Для этого в Windows (который имеет неудобные соглашения об именах файлов) просто запустите git bash в каталоге и запустите команду:
Эта команда просто делает пустой файл .gitkeep в текущем каталоге
dummy.txt способ: dummy.txt
Другой взлом для этого очень похож на выше, и те же шаги могут быть выполнены, но вместо .gitkeep просто используйте вместо него dummy.txt . Это дает дополнительный бонус, позволяющий легко создавать его в Windows с помощью контекстного меню. И вы также можете оставить в них смешные сообщения. Вы также можете использовать файл .gitkeep для отслеживания пустого каталога. .gitkeep обычно представляет собой пустой файл, который добавляется для отслеживания пустой строки.
Поиск файлов, игнорируемых .gitignore
Вы можете перечислить все файлы, игнорируемые git в текущем каталоге командой:
Итак, если у нас есть структура репозитория, вот так:
. и .gitignore файл, содержащий:
. чем результат команды будет:
Если вы хотите перечислить рекурсивно проигнорированные файлы в каталогах, вам нужно использовать дополнительный параметр — —untracked-files=all