Как узнать какие файлы не отслеживаются git

Обновлено: 07.07.2024

Я клонировал проект, содержащий некоторые .csproj файлы. Мне не нужны/как локальные файлы csproj , которые отслеживаются Git (или воспитываются при создании патча), но явно они необходимы в проекте.

Я добавил *.csproj в свой LOCAL .gitignore , но файлы уже находятся в репо.

Когда я набираю статус Git, он показывает мои изменения на csproj , которые меня не интересуют отслеживание или отправка патчей.

Как удалить "отслеживание" этих файлов из моего личного репо (но сохраните их в источнике, чтобы я мог их использовать), чтобы я не видел изменений, когда я делаю статус (или создаю патч )?

ОТВЕТЫ

Ответ 1

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

Обратите внимание, что это решение удаляет файлы из репозитория, поэтому всем разработчикам необходимо будет поддерживать собственные локальные (неконтролируемые контролируемые) копии файла

Чтобы предотвратить git от обнаружения изменений в этих файлах, вы также должны использовать эту команду:

Что вы, вероятно, захотите сделать: (ниже @Ryan Taylor answer)

  1. Это означает, что git вам нужна собственная независимая версия файла или папки. Например, вы не хотите перезаписывать (или удалять) создания/создания конфигурационных файлов.

Ответ 2

Если вы выполняете git update-index --assume-unchanged file.csproj , git не будет автоматически проверять файл .csproj на изменения: это остановит их при появлении статуса git при каждом изменении. Таким образом, вы можете пометить все ваши файлы .csproj таким образом, хотя вам придется вручную отмечать любые новые, которые отправляет вам репозиторий вверх. (Если у вас их есть в .gitignore или .git/info/exclude , то те, которые вы создаете, будут проигнорированы)

Я не совсем уверен, какие файлы .csproj. если они что-то вроде линий IDE-конфигураций (похожие на файлы Eclipse.eclipse и .classpath), то я бы предложил, чтобы они никогда не были источником - контролируется вообще. С другой стороны, если они являются частью системы сборки (например, Make файлы), то ясно, что они должны --- и способ получить дополнительные локальные изменения (например, из local.csproj a la config.mk) будет полезен: разделите сборку на глобальные части и локальные переопределения.

Ответ 3

1. Это сохранит локальный файл для вас, но удалит его для всех остальных, когда они извлекут.

git rm --cached <file-name> или git rm -r --cached <folder-name>

2. Это для оптимизации, как папка с большим количеством файлов, например SDK, которые, вероятно, никогда не изменятся. Он говорит git прекратить проверять эту огромную папку каждый раз на предмет изменений, локально, так как у нее их нет. Индекс assume-unchanged будет сброшен и файл будут перезаписаны, если в файл/папку будут внесены изменения в исходном режиме (при извлечении).

3. Это означает, что Git хочет иметь собственную независимую версию файла или папки. Например, вы не хотите перезаписывать (или удалять) файлы рабочей/промежуточной конфигурации.

Важно знать, что git update-index не будет распространяться с помощью git, и каждому пользователю придется запускать его независимо.

Ответ 4

Это двухэтапный процесс:

Удалите отслеживание файла/папки - но сохраните их на диске - используя

Теперь они не отображаются как "измененные", но все равно отображаются как

Добавьте их в .gitignore

Ответ 5

Принятый ответ по-прежнему не работает для меня

git rm -r --cached.

git добавить.

git commit -m "fixing .gitignore"

Найден ответ от здесь

Ответ 6

Если у вас есть весь проект локально, но забыл добавить вас git игнорировать и теперь отслеживать некоторые ненужные файлы, используйте эту команду, чтобы удалить все

убедитесь, что вы находитесь в корне проекта.

Затем вы можете сделать обычный

Добавить

Зафиксировать

Нажмите

Заключение

Надеюсь, что это поможет людям, которые должны внести изменения в их .gitignore или забыли все вместе.

  • Удаляет весь кеш
  • Посмотрим на ваш .gitignore
  • Добавляет файлы, которые вы хотите отслеживать
  • Отбрасывает ваше репо

Ответ 7

Как указано в других ответах, выбранный ответ неверен.

ответ на другой вопрос предполагает, что это может быть skip-worktree, который потребуется.

Ответ 8

Чтобы сэкономить время, правила, которые вы добавляете в свой .gitignore, можно использовать для удаления нескольких файлов/папок i.e.

git rm --cached app/**/*.xml

git rm --cached -r app/widgets/yourfolder/

Ответ 9

Чтобы предотвратить мониторинг файла с помощью git

И чтобы вернуть его обратно используйте

Ответ 10

Многие люди советуют вам использовать git update-index --assume-unchanged . Действительно, это может быть хорошим решением, но только в краткосрочной перспективе.

Что вы, вероятно, хотите сделать, это: git update-index --skip-worktree .

(Третий вариант, который вам, вероятно, не нужен: git rm --cached . Он сохранит ваш локальный файл, но будет помечен как удаленный из удаленного хранилища.)

Разница между первыми двумя вариантами?

  • assume-unchanged временно позволяет скрывать изменения из файла. Если вы хотите скрыть изменения, внесенные в файл, изменить файл, а затем извлечь другую ветку, вам придется использовать no-assume-unchanged , а затем, вероятно, скрыть сделанные изменения.
  • skip-worktree будет следовать за вами независимо от того, какую ветку вы заказываете, с вашими изменениями!

Вариант использования assume-unchanged

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

Мне нравится использовать его, когда я хочу только на некоторое время остановить отслеживание изменений + зафиксировать кучу файлов ( git commit -a ), связанных с той же модификацией.

Вариант использования skip-worktree

У вас есть класс настройки, содержащий параметры (например, включая пароли), которые ваши друзья должны изменить в соответствии со своими настройками.

  • 1. Создайте первую версию этого класса, заполните поля, которые вы можете заполнить, и оставьте другие поля пустыми/пустыми.
  • 2. Зафиксируйте и отправьте на удаленный сервер.
  • 3: git update-index --skip-worktree MySetupClass.java
  • 4. Обновите свой класс конфигурации с помощью своих собственных параметров.
  • 5: вернуться к работе над другой функциональностью.

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

PS: делайте одно или другое, но не оба, так как у вас будут нежелательные побочные эффекты. Если вы хотите попробовать другой флаг, вы должны сначала отключить его.

Ответ 11

Чтобы запретить Git отслеживать изменения в вашем локальном файле/папке (т.е. git status не обнаружит изменения в нем), выполните:

И чтобы Git снова отслеживал изменения в вашей локальной версии (чтобы вы могли зафиксировать изменения), выполните:

Ответ 12

однострочный ответ git update-index --assume-unchanged [path]

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

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

Ответ 13

Я предполагаю, что вы спрашиваете, как удалить ВСЕ файлы в определенной папке или в папку bin, а не выбирать каждый файл отдельно.

Вы можете использовать эту команду:

git rm -r -f /<floder-name>\*

Убедитесь, что вы находитесь в родительском каталоге каталога.
Эта команда будет рекурсивно "удалять" все файлы, находящиеся в файле bin/или build/folders. Под словом delete я подразумеваю, что git будет притворяться, что эти файлы "удалены", и эти файлы не будут отслеживаться. git действительно отмечает, что эти файлы находятся в режиме удаления.

Убедитесь, что ваш .gitignore готов к предстоящим фиксациям.
Документация: git rm

Ответ 14

Проблема может быть вызвана порядком работы. Если вы сначала изменили .gitignore, тогда git rm --cached xxx, вам, возможно, придется столкнуться с этой проблемой.

Правильное решение:

  • git rm --cached xxx
  • изменен .gitignore

Инвариант заказа!

Перезагрузите .gitignore после изменения!

Ответ 15

Я предполагаю, что вы пытаетесь удалить один файл из git. для этого я бы рекомендовал ниже команду.

git update-index -assume-неизменный

Ex - git update-index --assume-unchanged .gitignore.idea/compiler.xml

Ответ 16

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

В приведенном ниже тексте "excirir" - это имя каталога, в который я не хочу смотреть изменения.

Сначала удалите все существующие новые файлы из кэша отслеживания изменений (без удаления из файловой системы).

Вы можете сделать то же самое с modified: . renamed: немного сложнее, так как вам нужно посмотреть бит post -> для нового имени файла и выполнить бит pre -> , как описано для deleted: ниже.

Файлы deleted: оказываются немного сложнее, так как невозможно обновить индекс для файла, который не существует в локальной системе

Последняя команда в приведенном выше списке снова удалит файлы из вашей файловой системы, поэтому не стесняйтесь опускать это.

Затем заблокируйте отслеживание изменений из этого каталога

Ответ 17

В этом ответе был дан почти подход без команды:

Чтобы игнорировать определенные файлы для каждого локального репо:

/.gitignore_global , например, touch

Чтобы игнорировать определенные файлы для одного локального репо:

  1. Выполните описанный выше третий шаг для файла .git/info/exclude в репозитории, то есть запишите пути к файлам/каталогам, которые вы хотите игнорировать, в .git/info/exclude . например modules/*.C , который, как предполагается, будет находиться в вашем рабочем каталоге, то есть $WORK_DIR/modules/*.C .

Ответ 18

Применить .gitignore к настоящему/будущему

Этот метод применяет стандартное поведение .gitignore, и не требует ручного указания файлов, которые необходимо игнорировать.

Can't use --exclude-from=.gitignore anymore : / - Here the updated method:

Общий совет: начните с чистого репо - все зафиксировано, ничего не ожидает в рабочем каталоге или индексе, и сделайте резервную копию!

Если вам также необходимо удалить недавно проигнорированные файлы из истории фиксации ветки или если вы не хотите, чтобы недавно проигнорированные файлы были удалены из будущих операций, см. этот ответ.

Команда git status отображает состояние рабочего каталога и раздела проиндексированных файлов. С ее помощью можно проверить индексацию изменений и увидеть файлы, которые не отслеживаются Git. Информация об истории коммитов проекта не отображается при выводе данных о состоянии. Для этого используется команда git log .

Связанные команды git

    • Теги — это ссылки, указывающие на определенные точки в истории Git. Команда git tag обычно используется для захвата некой точки в истории, которая используется для релиза нумерованной версии (например, v1.0.1).
    • Общее назначение git blame — отображение метаданных автора, связанных со строками, которые были внесены в файл при коммите. Таким образом можно проследить историю кода и выяснить, какой именно код был внесен в репозиторий, как это было сделано и по какой причине.
    • Команда git log отображает отправленные снимки состояния и позволяет просматривать и фильтровать историю проекта, а также проводить поиск по ней.

    Использование

    Выводит список проиндексированных и неотслеживаемых файлов, а также файлов, удаленных из индекса Git.

    Пояснения

    Игнорирование файлов

    Неотслеживаемые файлы обычно подразделяются на две категории: файлы, недавно добавленные в проект и пока не отправленные в качестве коммитов, либо скомпилированные бинарные файлы (например, .pyc , .obj , .exe и т. д.). Включать файлы первой категории в выходные данные git status очень полезно, в то время как файлы второй категории могут затруднить отслеживание изменений в репозитории.

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

    Пример

    Перед отправкой изменений рекомендуется проверить состояние репозитория. Так вы сможете убедиться, что коммит включает только нужные данные. В следующем примере показано состояние репозитория до и после индексирования и отправки снимка состояния:

    Первая строка данных о состоянии указывает на файл, который не был проиндексирован. Операция git add отражена во второй команде git status , а в последней строке данных сообщается, что элементы для коммита отсутствуют (рабочий каталог соответствует последнему коммиту). Для некоторых команд Git (например, git merge ) требуется очистка рабочего каталога, чтобы исключить случайную перезапись изменений.

    git log

    Команда git log отображает отправленные снимки состояния и позволяет просматривать и фильтровать историю проекта, а также искать в ней конкретные изменения. С помощью git status можно просматривать рабочий каталог и раздел проиндексированных файлов, в то время как git log показывает только историю коммитов.

    Существует множество вариантов для настройки выходных данных команды git log: от простой фильтрации коммитов до их отображения в пользовательском формате. Ниже показаны наиболее распространенные конфигурации git log .

    Использование

    Выводит полную историю коммитов в стандартном формате. Если выходные данные занимают более одного экрана, можно выполнить прокрутку с помощью клавиши Пробел или нажать q для выхода.

    Записывает каждый коммит в одну строку. Так можно получить подробный обзор всей истории проекта.

    Кроме обычных данных git log указывается, какие файлы были изменены, а также относительное число добавленных или удаленных строк в каждом из них.

    Выводит патчи, соответствующие определенным коммитам. Это самое подробное представление истории проекта, поскольку так можно просмотреть полный список изменений каждого коммита.

    Выполняет поиск коммитов конкретного автора. Аргумент

    может быть обычной строкой или регулярным выражением.

    . Этот аргумент может быть обычной строкой или регулярным выражением.

    Отображает только коммиты в диапазоне значений и . Эти аргументы могут быть идентификаторами коммитов, именами веток, указателями HEAD или другими ссылками на версии.

    Выводит только коммиты, содержащие указанный файл. Так можно удобно просмотреть историю конкретного файла.

    Пояснения

    Команда git log является основным инструментом Git для изучения истории репозитория. С помощью этой команды можно найти конкретную версию проекта или определить изменения, которые будут внесены при выполнении слияния в функциональной ветке.

    Большая часть этой информации проста для понимания, но все же первую строку стоит пояснить. Строка длиной 40 знаков, следующая за элементом commit , является контрольной суммой SHA‑1 содержимого коммита. Она играет роль механизма для обеспечения целостности коммита (при нарушении целостности контрольная сумма изменится) и служит для него уникальным идентификатором.

    Этот идентификатор может использоваться в таких командах, как git log .. , в качестве ссылки на конкретные коммиты. Так, команда git log 3157e..5ab91 отображает данные в диапазоне между коммитами с идентификаторами 3157e и 5ab91 . Кроме контрольных сумм, на конкретные коммиты указывают имена веток (см. раздел Модуль веток) и ключевое слово HEAD , которое всегда ссылается на текущий коммит, будь то ветка или конкретный коммит.

    используется для относительных ссылок на родительский элемент коммита. Например, 3157e

    1 ссылается на коммит, предшествующий коммиту 3157e , а HEAD

    3 находится на 3 уровня выше текущего коммита.

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

    Пример

    В разделе Использование приводится множество примеров использования git log , однако следует помнить, что в одной команде можно объединить несколько параметров:

    Эта команда выводит данные по всем изменениям, которые Джон Смит внес в файл hello.py .

    Синтаксис «..» удобно использовать при сравнении веток. В следующем примере показана команда для вывода краткого обзора всех коммитов, которые включены в ветку some-feature и не включены в main .

    есть ли способ, чтобы использовать команду git ls-files показывать только неотслеженные файлы?

    причина, по которой я спрашиваю, заключается в том, что я использую следующую команду для обработки всех удаленных файлов:

    Я хотел бы что-то похожее на неотслеживаемые файлы:

    я смог найти до git ls-files , но это не то, что я хочу, потому что это также показывает игнорируемые файлы. Я также смог придумать следующие длинные и уродливые команда:

    похоже, что должна быть лучшая команда, которую я могу использовать здесь. А если нет, как создать пользовательские команды git?

    чтобы перечислить неотслеженные файлы, попробуйте:

    хороший псевдоним для добавления неотслеживаемые файлы:

    Edit: Для справки: git-ls-files

    если вы просто хотите удалить все неотслеживаемые файлы, сделайте следующее:

    добавить x к этому, если вы хотите также включить специально игнорируемые файлы. Я использую git clean -dfx a много в течение дня.

    вы можете создать пользовательский git, просто написав скрипт под названием git-whatever и имея его на своем пути.

    git add -A -n будет делать то, что вы хотите. -A добавляет все неотслеживаемые файлы в репо, -n делает dry-run где добавление не выполняется, но вывод состояния дается список каждого файла, который б добавлены.

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

    все очень просто

    чтобы получить список всех неотслеженных файлов используйте команду git статус С опции - u (--untracked-files)

    при поиске файлов для потенциального добавления. Вывод из git show делает это, но он также включает в себя много других вещей. Следующая команда полезна для получения того же списка файлов, но без всех других вещей.

    это полезно при объединении в конвейере, чтобы найти файлы, соответствующие определенному шаблону, а затем трубопровод, который git add .

    Я знаю его старый вопрос, но с точки зрения списка неотслеженных файлов я думал, что добавлю еще один, который также перечисляет неотслеженные папки:

    вы можете использовать операцию git clean с -n (dry run), чтобы показать вам, какие файлы он удалит (включая .gitignore files) by:

    это имеет то преимущество, что показывает все файлы и все папки которые не отслеживаются. Параметры:

    git config --global user.name "[name]" — установить имя, которое будет прикрепляться к коммиту.

    git config --global user.email "[email address]" — установить email, который будет прикрепляться к коммиту.

    git config --global color.ui auto — включить полезную подсветку командной строки.

    git config --global push.default current — обновлять удаленную ветку с таким же именем, что и локальная, при пуше изменений (если не указано иного).

    git config --global diff.tool [tool] — установить программу для разрешения конфликтов при слиянии.

    Создание репозиториев

    git init [project-name] — создать новый локальный репозиторий с заданным именем.

    git clone [url] — загрузить проект и его полную историю изменений.

    Работа с изменениями

    git status — полный список изменений файлов, ожидающих коммита.

    git status -s — краткий вид изменений.

    git diff — показать изменения в файлах, которые еще не были добавлены в индекс коммита (staged).

    git add [file] — сделать указанный файл готовым для коммита.

    git add . — сделать все измененные файлы готовыми для коммита.

    git add '*.txt' — добавить только файлы, соответствующие указанному выражению.

    git add --patch filename — позволяет выбрать какие изменения из файла добавятся в коммит.

    git diff --staged — показать что было добавленно в индекс с помощью git add , но еще не было закоммиченно.

    git diff HEAD — показать что изменилось с последнего коммита.

    git diff HEAD^ — показать что изменилось с предпоследнего коммита.

    git diff [branch] — сравнить текущую ветку с заданной.

    git difftool -d — то же самое, что и diff , но показывает изменения в заданной difftool.

    git difftool -d master.. — показать изменения, сделанные в текущей ветке.

    git diff --stat — показать статистику какие файлы были изменены и как.

    git reset [file] — убрать файлы из индекса коммита (изменения не теряются).

    git commit --amend — добавить изменения к последнему коммиту.

    Работа с ветками

    git branch — список всех локальных веток в текущей директории.

    git branch [branch-name] — создать новую ветку.

    git checkout [branch-name] — переключиться на указанную ветку и обновить рабочую директорию.

    git checkout -b <name> <remote>/<branch> — переключиться на удаленную ветку.

    git checkout [filename] — вернуть файл в первоначальное состояние если он еще не был добавлен в индекс коммита.

    git merge [branch] — соединить изменения в текущей ветке с изменениями из заданной.

    git merge --no-ff [branch] — соединить ветки без режима “fast forwarding”.

    git branch -a — посмотреть полный список локальных и удаленных веток.

    git branch -d [branch] — удалить заданную ветку.

    git branch -D [branch] — принудительно удалить заданную ветку, игнорируя ошибки.

    git branch -m <oldname> <newname> — переименовать ветку.

    Работа с файлами

    git rm [file] — удалить файл из рабочей директории и добавить в индекс информацию об удалении.

    git rm --cached [file] — удалить файл из репозитория, но сохранить его локально.

    git mv [file-original] [file-renamed] — изменить имя файла и добавить в индекс коммита.

    Отслеживание файлов

    .gitignore — текстовый файл, в котором задаются правила для исключения файлов из репозитория. Например:

    git ls-files --other --ignored --exclude-standard — список всех игнорируемых файлов.

    Сохранение фрагментов

    git stash — положить во временное хранилище все отслеживаемые файлы.

    git stash pop — восстановить последние файлы, положенные во временное хранилище.

    git stash list — список всех сохраненных изменений во временном хранилище.

    git stash drop — удалить последние файлы, положенные во временное хранилище.

    Просмотр истории

    git log — список изменения текущей ветки.

    git log --follow [file] — список изменения текущего файла, включая переименования.

    git log --pretty=format:"%h %s" --graph — изменение вида отображения истории изменений.

    git log --author='Name' --after= --pretty=oneline --abbrev-commit — посмотреть над чем работал заданный пользователь последнюю неделю.

    git log --no-merges master.. — посмотреть историю изменений только для текущей ветки.

    git diff [file-branch]..[second-branch] — посмотреть различия между двумя заданными ветками.

    git show [commit] — показать метадату и изменения в заданном коммите.

    git show [branch]:[file] — посмотреть на файл в другой ветке, не переключаясь на неё.

    Отмена коммитов

    git reset — убрать изменения из индекса коммита, сами изменения останутся.

    git reset [commit/tag] — отменить все коммиты после указанного коммита, изменения будут сохранены локально.

    git reset --hard [commit] — принудительно вернутся к указанному коммиту, не сохраняя историю и изменения.

    Синхронизация изменений

    git fetch [bookmark] — загрузить всю историю с заданного удаленного репозитория.

    git merge [bookmark]/[branch] — слить изменения локальной ветки и заданной удаленной.

    git push — запушить текущую ветку в удаленную ветку.

    git push [remote] [branch] — запушить ветку в указанный репозиторий и удаленную ветку.

    git push [bookmark] :[branch] — в удаленном репозитории удалить заданную ветку.

    git push -u origin master — если удаленная ветка не установлена как отслеживаемая, то сделать ее такой.

    git pull — загрузить историю и изменения удаленной ветки и произвести слияние с текущей веткой.

    git pull [remote][branch] — указать конкретную удаленную ветку для слияния.

    git remote — посмотреть список доступных удаленных репозиториев.

    git remote -v — посмотреть детальный список доступных удаленных репозиториев.

    Все файлы проекта находятся в папке base_fldr. Также у меня есть несколько папок внутри base_fldr, называемых sub_fldr1 и sub_fldr2. Эти подпапки также содержат некоторые файлы.

    Если я изменяю какой-либо из файлов в моем base_fldr или base_fldr \ sub_fldr \, тогда git status показывает их как измененные. Также, если я добавлю новый файл в base_fldr, git status покажет его как неотслеживаемый файл.

    Моя проблема в том, что если я добавляю новый файл в base_fldr \ sub_fldr \, тогда статус git не показывает файл как неотслеживаемый. Он даже не даст никакой информации о файле.

    Файл или его расширение НЕТ в моем списке .gitignore. Также я попробовал git add sub_fldr \ file_name, но ни ошибка, ни добавление файла в индекс.

    Есть идеи, что здесь происходит? Спасибо!

    Я понял, что пошло не так. По сути, первая строка в моем файле .gitignore - «* /». Это приводит к тому, что любой файл, добавленный в подкаталог, игнорируется командой git status. Но самое забавное, что если я изменяю какие-либо файлы в подпапке, git status правильно показывает их как измененные, поскольку файл уже находится в репозитории git, но игнорирует новые файлы в подпапке.

    Я исправил свою проблему, удалив строку в файле .gitignore, чтобы не игнорировать изменения в подпапках, затем добавил новые файлы в индекс, а затем снова добавил строку в .gitignore, чтобы он игнорировал любые сгенерированные файлы в подпапках.

    Спасибо всем за ответы.

    Вероятно, это связано с тем, что ваш каталог base_fldr \ sub_fldr \ не отслеживается, если вы запустите:

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

    По умолчанию git не будет отображать файлы в каталогах, которые не отслеживаются.

    У меня возникла аналогичная проблема с отсутствующими отслеживаемыми файлами. Экспериментируя со способами управления локально измененными версиями отслеживаемых файлов без необходимости постоянно избегать случайных коммитов, я выполнил следующее:

    В итоге я отказался от этой идеи, но забыл отменить команду, поэтому последующие изменения этого и других файлов --assume-unchanged полностью отсутствовали:

    Мне потребовалось время, чтобы понять, что происходит, но мне просто пришлось отменить команду с помощью:

    У вас есть подкаталог .git внутри каталога sub_fldr ? Git может подумать, что вы пытаетесь использовать подмодули .

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

    Это покажет все неотслеживаемые файлы, подчиняясь файлу .gitignore .

    git ls-files --other --directory

    Это покажет все неотслеживаемые файлы, не подчиняясь файлу .gitignore .

    Какие бы файлы ни присутствовали в выводе 2 , но не присутствуют в выводе 1 , они не отображаются в неотслеживаемом виде из-за наличия какого-либо флага в вашем файле .gitignore

    Вот еще одна причина поведения, описанного в этом вопросе (список неотслеживаемых файлов git status не включает неотслеживаемый файл в подпапке). Если файл не отслеживается из-за наличия файла .gitignore в подпапке , то этот файл не будет включен в список неотслеживаемых файлов git status.

    С 2011 года это впервые было исправлено в Git v1.8.3-rc0 (апрель 2013 года).
    Он исправляет несколько проблем в коде, чтобы пройти по рабочему дереву в поисках неотслеживаемых и / или проигнорированных файлов, очищает и оптимизирует путь кода в целом.

    dir.c : заставить 'git-status --ignored' работать в пределах ведущих каталоги

    Подписано: Карстен Блис

    ' git status --ignored path/ 'не перечисляет игнорируемые файлы и каталоги в' path ', если какой-либо компонент' path 'классифицируется как неотслеживаемый.

    Отключите флаг DIR_SHOW_OTHER_DIRECTORIES при просмотре ведущих каталогов. Это предотвращает прерывание treat_leading_path() с флагом DIR_SHOW_IGNORED в неотслеживаемом каталоге верхнего уровня.

    В качестве побочного эффекта это также исключает рекурсивное сканирование каталогов на каждом уровне ведущего каталога, поскольку treat_directory() больше не может вызывать read_directory_recursive() при вызове из treat_leading_path() .

    Но, 6 лет спустя (конец 2019 г.), с Git 2.25 (1 квартал 2020 г.), различные исправления API обхода каталогов . отмените это исправление, показанное выше, и повторно внедрите его.

    Читайте также: