Не работает файл gitignore

Содержание

.gitignore не работает
24 ответов
.gitignore не работает
24 ответов:

.gitignore не работает

мой .gitignore файл, похоже, игнорируется git-может ли .gitignore файл будет поврежден? Какой формат файла, язык или культура ожидает git?

вывод git status :

Я бы debug.log и nbproject/ не отображается в списке игнорируемых файлов.

где я должен начать искать, чтобы это исправить?

24 ответов

даже если вы не отслеживали файлы до сих пор, git, похоже, может «знать» о них даже после их добавления в .gitignore .

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

затем выполните следующие команды из верхней папки вашего репозитория git:

когда .файл gitignore не работает (добавление чего-то.gitignore файл или удаление чего-то из .gitignore file), вы можете проверить следующие советы:

вы должны обратить внимание на глобальный файл gitignore, который иногда может повлиять на ваш gitignore.

когда вы добавляете что-то.gitignore файл, как человек, который ответил этот вопрос первый:

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

«тип файла» означает файл или тип файла, который вы хотите удалить из .файла.gitignore Вы хотите, чтобы тип файла отслеживался снова.

исправлено. Хорошо, я создал .файл gitignore в блокноте на windows, и он не работал. Когда я смотрел .файл gitignore в linux выглядел как организованная тарабарщина — возможно, Блокнот написал unicode, а не ascii или что-то еще 8-битное.

поэтому я переписал файл на моем linux box, и когда я вытащил его обратно в windows, он отлично работает! Ура!

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

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

еще одна причина этой проблемы-пробелы или вкладки перед инструкцией:

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

Я заметил, что кодировка .gitignore был эффект-если файл был Unicode, он был проигнорирован, если это был ASCII, это не было.

Проверка статуса: PS> git status
создайте функцию для Get-FileEncoding
тест .gitignore с кодировкой: PS> Get-FileEncoding .gitignore
изменить кодировку в ASCII: PS> Set-Content .gitignore -Encoding Ascii -Value (Get-Content .gitignore)
подтвердить: PS> git status

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

У меня были лучшие результаты с этим:

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

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

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

также проверить каталог, где тебя положить .гитюдного Он должен быть в корень вашего проекта:

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

Это то, что я сделал, чтобы исправить проблему:

скопируйте файлы во временную папку
удалите их из моей папки проекта.
зафиксируйте изменения, которые удаляют эти файлы из РЕПО
повторно добавил Эти файлы в мою папку проекта

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

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

есть еще одна проблема с .gitignore Это может произойти, особенно для пользователя windows, git не нравится, когда вы называете .gitignore (например, unity.gitignore ). Вы всегда захотите назвать его .gitignore , или на windows, .gitignore. как Windows думает, что вы пытаетесь переименовать его без имени.

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

я использовал это, чтобы создать файл ignore:

echo «node_modules» > .gitignore

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

echo node_modules > .gitignore

для меня ни один из вышеперечисленных ответов не работал. Я должен был скопировать .gitignore текст найти

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

У меня была такая же проблема. Я считаю, что проблема заключалась в несоответствии CR vs CR+LF. Я прятала вещи в своей .gitignore с помощью cmd (в windows 7) и следующей команды:

проблема заключалась в том, что эта команда не помещает правильный маркер конца строки для Git для распознавания новых строк (либо CR, либо CR+LF, когда git ожидает другой.) Я решил проблему, вручную заменив каждую новую строку в vim (vim на помощь!) и это сработало отлично.

попробуйте отредактировать .gitignore в Notepad++ или vim (в идеале), даже если файл выглядит правильно отформатированным, попробуйте заменить новые строки. Звучит странно, я знаю, но сработало на меня. : D

у меня была эта проблема, с a .gitignore, содержащий эту строку:

Я только что понял, что на самом деле этот каталог является символической ссылкой на папку где-то еще:

в строке lib/ext/ , git на самом деле ищет папку, но символическая ссылка-это , поэтому моя папка lib не игнорируется.

я исправил это путем замены lib/ext/ by lib/ext на мой .гитюдного.

специально для пользователей Windows: Если вы распаковали файлы и очистка/удаление кэшированных файлов не работает. Попробуйте открыть powershell и преобразовать .файл gitignore в кодировке UTF-8.

1)$Myfile = Get-Content ..gitignore

2)$Myfile = / Out-файл-кодировка «UTF8».gitignore

нужно только сделать это один раз, чтобы закодировать .файл gitignore для этого каталога, и поскольку файл затем кодируется правильно всякий раз, когда вы редактируете файл в в будущем это должно сработать. Я считаю, что это связано с глюком, когда GitHub не собирается читать кодировку не UTF-8 для a .файла.gitignore Насколько мне известно, эта проблема еще не решена для Windows. Не слишком большое дело, просто боль для отладки, когда она не работает.

моя проблема была (как предложил ОП) коррумпированной .файла.gitignore Я не верил в это и игнорировал возможность, пока все остальное не провалилось. Коррупция не появился в vi , но в начале файла было два байта, которые вызвали .файл gitignore следует игнорировать. Для меня они появились только тогда, когда я набрал cat .gitignore , который показал:

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

одна вещь, чтобы также посмотреть, это вы сохраняете свой .файл gitignore с правильными окончаниями строк?

WINDOWS: Если вы используете его в windows, вы сохраняете его с окончаниями строк windows? Не все программы будут делать это по умолчанию, notepad++ и многие редакторы php по умолчанию для Linux, поэтому файлы будут совместимы с сервером. Один из простых способов проверить это, является открытие файла в Windows notepad. Если все отображается в одной строке, то файл был сохранен в строке linux окончания.

LINUX: Если у вас возникли проблемы с файлом, работающим в среде linux. Откройте файл в Редакторе, таком как emacs или nano. Если вы видите какие-либо непечатаемые символы, то файл был сохранен с окончаниями строк windows.

хорошо, поэтому в моем случае принятое решение не сработало, и то, что сработало, описано здесь:

Закройте Visual Studio.
перейдите к вашей .папку с Git
удалить ms-persist.в XML
Перезапустите Visual Studio

надеюсь, что это поможет кому-то когда-нибудь

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

The .файл gitignore не будет работать, если у вас есть встроенные комментарии, например:

измените его на это:

У меня была небольшая проблема с этим. Я смог пойти в www.GitHub.com/project и удалите файл с пользовательским интерфейсом и добавьте это изменение в мастер-РЕПО.

похоже, я добавил файл в репо, прежде чем я сделал .гитюдного. Кажется, это работает.

Если вы пользователь Notepad++, попробуйте сделать следующее:

открыть свой .файл gitignore с помощью Notepad++ и do:

изменить > преобразование EOL > формат Windows > сохранить

попробуйте снова использовать статус git и посмотрите, сработало ли это для вас.

Я опубликовал ответ на аналогичный вопрос здесь.

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

таким образом, добавление еще одной строки исправлено это:

Источник

.gitignore не работает

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

вывод git status :

Я бы debug.log и nbproject/ не отображается в списке игнорируемых файлов.

где я должен начать искать, чтобы это исправить?

24 ответов:

даже если вы до сих пор не отслеживали файлы, git, похоже, может «знать» о них даже после их добавления в .gitignore .

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

затем выполните следующие команды из верхней папки вашего репозитория git:

когда .gitignore файл не работает (добавление чего-то в .gitignore файл или удаление чего-то из .gitignore file), вы можете проверить следующие советы:

вы должны обратить внимание на глобальный файл gitignore, который иногда может повлиять на ваш gitignore.

когда вы что-то добавить .gitignore файл, как человек, который ответил этот вопрос первый:

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

«тип файла» означает файл или тип файла, который вы хотите удалить из файла .файла.gitignore Вы хотите, чтобы тип файла отслеживался снова.

исправлено. Хорошо, я создал его .gitignore файл в блокноте на windows, и он не работал. Когда я смотрел на него .файл gitignore в linux выглядел как организованная тарабарщина-возможно, Блокнот выписал unicode, а не ascii или что-то еще 8-битное.

поэтому я переписал файл на моем Linux box, и когда я вытащил его обратно в windows, он отлично работает! Ура!

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

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

еще одна причина этой проблемы-пробелы или вкладки перед оператором:

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

Я заметил, что кодировка .gitignore оказывает воздействие—если файл был в кодировке Юникод, он был проигнорирован, если он был в формате ASCII, это было не так.

Проверка статуса: PS> git status
создать функции Get-FileEncoding
тест .gitignore с кодировкой: PS> Get-FileEncoding .gitignore
изменить кодировку в ASCII: PS> Set-Content .gitignore -Encoding Ascii -Value (Get-Content .gitignore)
подтвердить: PS> git status

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

У меня были лучшие результаты с этим:

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

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

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

также проверить каталог, где тебя положить .gitignore Он должен быть в корень вашего проекта:

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

вот что я сделал, чтобы исправить проблему:

скопируйте файлы во временную папку
удалить их из папки проекта.
зафиксируйте изменения, которые удаляют эти файлы из РЕПО
повторно добавил Эти файлы в папку моего проекта

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

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

есть еще одна проблема с .gitignore Это может произойти, особенно для пользователя windows, git не нравится, когда вы называете .gitignore (например, unity.gitignore ). Вы всегда будете хотеть назвать его .gitignore , или на windows, .gitignore. как Windows думает, что вы пытаетесь переименовать его без имени.

Я просто столкнулся с этим вопросом. Содержание внутри меня .файл gitignore продолжал появляться в списке неотслеживаемых файлов.

я использовал это, чтобы создать файл ignore:

echo «node_modules» > .gitignore

оказывается, что двойные котировки были причиной проблемы для меня. Я удалил файл ignore, а затем снова использовал команду без кавычек, и она работала так, как ожидалось. Мне не нужно было возиться с кодировкой файла. Я нахожусь на машине Win10, используя Cmder.

echo node_modules > .gitignore

для меня ни один из вышеперечисленных ответов не работал. Я должен был скопировать .gitignore текст найти

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

У меня была такая же проблема. Я считаю, что проблема заключалась в несоответствии CR vs CR+LF. Я прятал вещи в моем .gitignore с помощью cmd (в windows 7) и следующей команды:

проблема заключалась в том, что эта команда не помещает правильный маркер конца строки для Git для распознавания новых строк (либо CR, либо CR+LF, когда git ожидает другой.) Я решил проблему, вручную заменив каждую новую строку в vim (vim to the rescue!) и это сработало отлично.

попробуйте отредактировать ваш .gitignore в Notepad++ или vim (в идеале), даже если файл выглядит так, как будто он отформатирован правильно, попробуйте заменить новые строки. Звучит странно, я знаю, но работал на меня. : D

у меня была эта проблема, с А.gitignore, содержащий эту строку:

Я только что понял, что на самом деле этот каталог является символической ссылкой на папку где-то еще:

в строке lib/ext/ , git на самом деле ищет папку, но символическая ссылка-это file, поэтому моя папка lib не игнорируется.

я исправил это путем замены lib/ext/ by lib/ext на мой .gitignore.

специально для пользователей Windows: Если у вас есть неотслеживаемые файлы и очистка/удаление кэшированных файлов не работает. Попробуйте открыть powershell и преобразовать его .gitignore файл в кодировке UTF-8.

1)$Myfile = Get-Content ..gitignore

2)$Myfile = | Out-File-Encoding «UTF8» .gitignore

нужно только сделать это один раз, чтобы закодировать .gitignore файл для этого каталога, и так как файл затем кодируется правильно всякий раз, когда вы редактируете файл в в будущем это должно сработать. Я считаю, что это связано с глюком, когда GitHub не собирается читать кодировку non UTF-8 для a .файла.gitignore Насколько мне известно, эта проблема еще не решена для Windows. Не слишком большое дело, просто боль для отладки, когда он не работает.

моя проблема была (как предложил ОП) коррумпированной .файла.gitignore Я не верил, что это так, и игнорировал эту возможность, пока все остальное не потерпело неудачу. Коррупция не появился в vi , но было два байта на начало файла, который вызвал.gitignore файл будет проигнорирован. Для меня они появились только тогда, когда я набрал cat .gitignore , который показал:

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

одна вещь, чтобы также посмотреть, это вы сохраняете ваш .gitignore файл с правильными окончаниями строк?

WINDOWS: Если вы используете его в windows, вы сохраняете его с окончаниями строк windows? Не все программы будут делать это по умолчанию, notepad++ и многие PHP-редакторы по умолчанию для окончаний строк linux, поэтому файлы будут совместимы с сервером. Один простой способ проверить это-открыть файл в блокноте windows. Если все отображается в одной строке, то файл был сохранен с помощью linux line окончания.

ок, так что в моем случае принятое решение не сработало, а то, что сработало описано здесь:

Закрыть Visual Studio.
перейдите к вашей .git folder
удалить ms-persist.xml
Перезапустить Visual Studio

надеюсь, что это поможет кому-то когда-нибудь

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

The .файл gitignore не будет работать, если у вас есть встроенные комментарии, например:

измените его на это:

У меня была небольшая проблема с этим. Я был в состоянии пойти в www.GitHub.com/project и удалите файл с пользовательским интерфейсом, и добавьте это изменение в мастер-РЕПО.

похоже, я добавил файл в репо, прежде чем я сделал .gitignore. Это, кажется, работает.

Если вы являетесь пользователем Notepad++, попробуйте сделать следующее:

открыть свой .gitignore файл с помощью Notepad++ и сделать:

редактировать > преобразование EOL > формат Windows > сохранить

попробуйте снова использовать статус git и посмотреть, сработало ли это для вас.

Я опубликовал ответ на аналогичный вопрос здесь.

для меня это была еще одна проблема. Мой. gitignore настроен игнорировать все, кроме вещей, которые я говорю ему не игнорировать. Вот такие:

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

Так что добавление еще одной строки исправлено это:

Источник