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

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

.gitignoreпредотвратит добавление неотслеживаемых файлов (без add -f) в набор файлов, отслеживаемых git, однако git продолжит отслеживать любые файлы, которые уже отслеживаются.

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

git rm --cached <file>

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

git rm -r --cached <folder>

Удаление файла из заголовка ревизии произойдет при следующем коммите.

ВНИМАНИЕ: Хотя это не удалит физический файл из вашего локального, он будет удалять файлы с машин других разработчиков на следующем git pull.

Приведенная ниже серия команд удалит все элементы из индекса Git (не из рабочего каталога или локального репо), а затем обновит индекс Git, соблюдая при этом git игнорирует. PS. Индекс = Кэш

Первый:

git rm -r --cached . 
git add .

Затем:

git commit -am "Remove ignored files"

Или однострочник:

git rm -r --cached . && git add . && git commit -am "Remove ignored files"

git update-index делает всю работу за меня:

git update-index --assume-unchanged <file>

Примечание. Это решение фактически не зависит от .gitignoregitignore только для неотслеживаемых файлов.

редактировать: так как этот ответ был опубликован, новая опция была создана, и это должно быть предпочтительным. Вы должны использовать --skip-worktreeэто для модифицированных отслеживаемых файлов, которые пользователь больше не хочет фиксировать, и сохранять --assume-unchangedпроизводительность, чтобы git не проверял состояние больших отслеживаемых файлов. См. Https://stackoverflow.com/a/13631525/717372 для получения более подробной информации ...

git update-index --skip-worktree <file>

git ls-files --ignored --exclude-standard -z | xargs -0 git rm --cached
git commit -am "Remove ignored files"

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

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

git ls-files --ignored --exclude-standard | sed 's/.*/"&"/' | xargs git rm -r --cached

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

уберите это, передайте, затем верните это обратно. Это работало для меня в прошлом. Вероятно, есть «более мерзкий» способ сделать это.

Если вы не можете git rmотследить файл, потому что это может понадобиться другим людям (предупреждение, даже если вы git rm --cached , когда кто-то другой получит это изменение, его файлы будут удалены в их файловой системе). Это часто делается из-за переопределения файла конфигурации, учетных данных аутентификации и т. Д. Пожалуйста, посмотрите на https://gist.github.com/1423106 способы, которыми люди обошли проблему.

Обобщить:

• Попросите ваше приложение найти пропущенный файл config-overide.ini и использовать его поверх зафиксированного файла config.ini (или, альтернативно, найдите ~ / .config / myapp.ini или $ MYCONFIGFILE)
• Зафиксируйте файл config-sample.ini и проигнорируйте файл config.ini, при необходимости создайте скрипт или аналогичный файл для копирования.
• Попробуйте применить магию gitattributes clean / smudge для применения и удаления изменений, например, размазать файл конфигурации как извлечение из альтернативной ветви и очистить файл конфигурации как извлечение из HEAD. Это сложная штука, я не рекомендую ее для начинающего пользователя.
• Сохраните файл конфигурации в выделенной для него ветке развертывания, которая никогда не объединяется с master. Когда вы хотите развернуть / скомпилировать / протестировать, вы сливаетесь с этой веткой и получаете этот файл. По сути, это подход smudge / clean, за исключением использования политик слияния людей и дополнительных git-модулей.
• Антирекомендация: не используйте предположения без изменений, это закончится только слезами (потому что ложная ложь сама по себе приведет к плохим вещам, таким как ваши изменения будут потеряны навсегда).

Используйте это когда:

1. Вы хотите распаковать много файлов, или

2. Вы обновили свой файл gitignore

Ссылка на источник: http://www.codeblocq.com/2016/01/Untrack-files-already-added-to-git-repository-based-on-gitignore/

Допустим, вы уже добавили / передали некоторые файлы в свой репозиторий git, а затем добавили их в свой .gitignore; эти файлы все еще будут присутствовать в вашем индексе репозитория. В этой статье мы увидим, как от них избавиться.

Шаг 1: внесите все ваши изменения

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

Шаг 2: Удалить все из хранилища

Чтобы очистить репо, используйте:

git rm -r --cached .

• rm это команда удаления
• -r позволит рекурсивное удаление
• –Cached удалит только файлы из индекса. Ваши файлы все еще будут там.

Команда rmможет быть неумолимой. Если вы хотите попробовать то, что он делает заранее, добавьте флаг -nили, --dry-runчтобы проверить это.

Шаг 3: заново добавить все

git add .

Шаг 4: совершить

git commit -m ".gitignore fix"

Ваш репозиторий чистый :)

Нажмите изменения на вашем пульте, чтобы увидеть изменения, действующие и там.

Я сделал это с помощью git filter-branch . Точная команда, которую я использовал, была взята со страницы руководства:

ВНИМАНИЕ : это удалит файл из всей вашей истории

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

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

Что не сработало для меня

(Под Linux) я хотел использовать посты, предлагающие ls-files --ignored --exclude-standard | xargs git rm -r --cachedподход. Тем не менее, (некоторые из) файлов, которые должны быть удалены, имеют встроенную новую строку / LF / \nв своих именах. Ни одно из решений:

git ls-files --ignored --exclude-standard | xargs -d"\n" git rm --cached
git ls-files --ignored --exclude-standard | sed 's/.*/"&"/' | xargs git rm -r --cached

справиться с этой ситуацией (получить ошибки о не найденных файлах).

Так что я предлагаю

git ls-files -z --ignored --exclude-standard | xargs -0 git rm -r --cached
git commit -am "Remove ignored files"

При этом используется -zаргумент для ls-файлов и -0аргумент для xargs для безопасного / правильного обслуживания «неприятных» символов в именах файлов.

На странице руководства git-ls-files (1) говорится:

Когда опция -z не используется, символы TAB, LF и обратная косая черта в путевых именах представляются как \ t, \ n и \\ соответственно.

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

1. Обновите свой .gitignoreфайл - например, добавьте папку, которую вы не хотите отслеживать .gitignore.

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

3. git add .- Все файлы будут добавлены обратно, кроме тех, что в .gitignore.

Шляпа на @AkiraYamamoto, чтобы указать нам правильное направление.

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

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

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

Эти 2 статьи были полезны для меня:

git предположить, что без изменений vs skip-worktree и как игнорировать изменения в отслеживаемых файлах с помощью Git

На основании этого я делаю следующее, если файл уже отслежен:

git update-index --skip-worktree <file>

С этого момента все локальные изменения в этом файле будут игнорироваться и не будут передаваться удаленно. Если файл изменяется на удаленном компьютере, конфликт может произойти, когда git pull. Тайник не сработает. Чтобы решить эту проблему, скопируйте содержимое файла в безопасное место и выполните следующие действия:

git update-index --no-skip-worktree <file>
git stash
git pull 

Содержимое файла будет заменено удаленным содержимым. Вставьте ваши изменения из безопасного места в файл и выполните снова:

git update-index --skip-worktree <file>

Если все, кто работает с проектом, будут выступать git update-index --skip-worktree <file>, проблемы с ним pullдолжны отсутствовать. Это решение подходит для файлов конфигурации, когда каждый разработчик имеет свою собственную конфигурацию проекта.

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

Делайте следующие шаги поочередно, у вас все будет хорошо.

1. удалите ошибочно добавленные файлы из каталога / хранилища . Вы можете использовать команду «rm -r» (для linux) или удалить их, просматривая каталоги. Или переместите их в другое место на вашем ПК. [Возможно, вам придется закрыть IDE, если вы хотите переместить / удалить ]

2. добавьте файлы / каталоги в gitignoreфайл и сохраните их.

3. удалите их из кэша git с помощью этих команд (если существует несколько каталогов, удалите их одну за другой, повторно выполнив эту команду)

git rm -r --cached path-to-those-files

4.Now сделать фиксации и нажим , использовать эти команды. Это удалит эти файлы из git remote и заставит git перестать отслеживать эти файлы.

git add .
git commit -m "removed unnecessary files from git"
git push origin

Копировать / вставить ответ git rm --cached -r .; git add .; git status

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

Ответ от Мэтта Фира был самым эффективным ИМХО. Ниже приведен сценарий PowerShell для тех, кто в Windows удаляет только файлы из своего репозитория git, которые соответствуют их списку исключений.

# Get files matching exclusionsfrom .gitignore
# Excluding comments and empty lines
$ignoreFiles =  gc .gitignore | ?{$_ -notmatch  "#"} |  ?{$_ -match  "\S"} | % {
                    $ignore = "*" + $_ + "*"
                    (gci -r -i $ignore).FullName
                }
$ignoreFiles = $ignoreFiles| ?{$_ -match  "\S"}

# Remove each of these file from Git 
$ignoreFiles | % { git rm $_}

git add .

Переместите или скопируйте файл в безопасное место, чтобы не потерять его. Затем откройте файл и выполните коммит. Файл все равно будет отображаться, если вы вернетесь к одному из этих предыдущих коммитов или к другой ветке, где он не был удален. Тем не менее, во всех будущих коммитах вы больше не увидите файл. Если файл находится в git ignore, вы можете переместить его обратно в папку, и git его не увидит.

Использование git rm --cachedкоманды не отвечает на исходный вопрос:

Как вы заставляете gitполностью забыть о [файле]?

Фактически, это решение приведет к удалению файла во всех остальных экземплярах репозитория при выполнении git pull!

Правильный способ заставить git забыть о файле задокументирован GitHub здесь .

Я рекомендую прочитать документацию, но в основном:

git fetch --all
git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch full/path/to/file' --prune-empty --tag-name-filter cat -- --all
git push origin --force --all
git push origin --force --tags
git for-each-ref --format='delete %(refname)' refs/original | git update-ref --stdin
git reflog expire --expire=now --all
git gc --prune=now

просто замените full/path/to/fileна полный путь к файлу. Убедитесь, что вы добавили файл в свой .gitignore.

Вам также нужно (временно) разрешить не-ускоренные пересылки в ваш репозиторий , так как вы изменяете свою историю git.

BFG специально разработана для удаления нежелательных данных , таких как большие файлы или пароли из Git РЕПО, так что имеет простой флаг , который будет удалять любой большой исторический (не-в-ваш-ток фиксации) файлов: «--strip-blobs- больше чем'

$ java -jar bfg.jar --strip-blobs-bigger-than 100M

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

$ java -jar bfg.jar --delete-files *.mp4

BFG в 10-1000 раз быстрее, чем git filter-branch, и, как правило, намного проще в использовании - для получения более подробной информации ознакомьтесь с полными инструкциями и примерами использования.

Источник: https://confluence.atlassian.com/bitbucket/reduce-repository-size-321848262.html

Если вы не хотите использовать интерфейс командной строки и работаете в Windows, очень простое решение - использовать TortoiseGit , в меню есть действие «Удалить (сохранить локальное)», которое работает нормально.

Мне понравился ответ JonBrave, но у меня есть достаточно грязные рабочие каталоги, которые фиксируют -a меня немного пугает, так что вот что я сделал:

git config --global alias.exclude-ignored '! git ls-files -z --ignored --exclude-standard | xargs -0 git rm -r --cached && git ls-files -z --ignored --exclude-standard | xargs -0 git stage && git stage .gitignore && git commit -m "новый gitignore и удаление игнорируемых файлов из индекса" '

ломая это:

git ls-files -z --ignored --exclude-standard | xargs -0 git rm -r --cached 
git ls-files -z --ignored --exclude-standard | xargs -0 git stage 
git stage .gitignore 
git commit -m "new gitignore and remove ignored files from index"

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

Это больше не проблема в последнем git (v2.17.1 на момент написания).

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

# Create empty repo
mkdir gitignore-test
cd gitignore-test
git init

# Create a file and commit it
echo "hello" > file
git add file
git commit -m initial

# Add the file to gitignore and commit
echo "file" > .gitignore
git add .gitignore
git commit -m gitignore

# Remove the file and commit
git rm file
git commit -m "removed file"

# Reintroduce the file and check status.
# .gitignore is now respected - status reports "nothing to commit".
echo "hello" > file
git status

В случае уже совершенного DS_Store:

find . -name .DS_Store -print0 | xargs -0 git rm --ignore-unmatch

Проигнорируйте их:

echo ".DS_Store" >> ~/.gitignore_global
echo "._.DS_Store" >> ~/.gitignore_global
echo "**/.DS_Store" >> ~/.gitignore_global
echo "**/._.DS_Store" >> ~/.gitignore_global
git config --global core.excludesfile ~/.gitignore_global

Наконец, сделайте коммит!

Специально для файлов на основе IDE, я использую это:

Например, slnx.sqlite, я просто полностью избавился от него следующим образом:

git rm {PATH_OF_THE_FILE}/slnx.sqlite -f
git commit -m "remove slnx.sqlite"

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

Принятый ответ не «заставляет Git » забывать « о файле ...» (исторически). Это только заставляет git игнорировать файл в настоящем / будущем.

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

Этот метод требует использования /.git/info/exclude(предпочтительнее) или уже существующий .gitignore в всех коммитах , которые имеют файлы , которые будут игнорироваться / забыто. ¹

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

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

Кроме того, комментарии / история изменений этого ответа ( и история изменений этого вопроса ) могут быть полезными / поучительными.

#commit up-to-date .gitignore (if not already existing)
#this command must be run on each branch

git add .gitignore
git commit -m "Create .gitignore"

#apply standard git ignore behavior only to current index, not working directory (--cached)
#if this command returns nothing, ensure /.git/info/exclude AND/OR .gitignore exist
#this command must be run on each branch

git ls-files -z --ignored --exclude-standard | xargs -0 git rm --cached

#Commit to prevent working directory data loss!
#this commit will be automatically deleted by the --prune-empty flag in the following command
#this command must be run on each branch

git commit -m "ignored index"

#Apply standard git ignore behavior RETROACTIVELY to all commits from all branches (--all)
#This step WILL delete ignored files from working directory UNLESS they have been dereferenced from the index by the commit above
#This step will also delete any "empty" commits.  If deliberate "empty" commits should be kept, remove --prune-empty and instead run git reset HEAD^ immediately after this command

git filter-branch --tree-filter 'git ls-files -z --ignored --exclude-standard | xargs -0 git rm -f --ignore-unmatch' --prune-empty --tag-name-filter cat -- --all

#List all still-existing files that are now ignored properly
#if this command returns nothing, it's time to restore from backup and start over
#this command must be run on each branch

git ls-files --other --ignored --exclude-standard

Наконец, следуйте остальной части этого руководства GitHub (начиная с шага 6), которое включает важные предупреждения / информацию о командах ниже .

git push origin --force --all
git push origin --force --tags
git for-each-ref --format="delete %(refname)" refs/original | git update-ref --stdin
git reflog expire --expire=now --all
git gc --prune=now

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

#fetch modified remote

git fetch --all

#"Pull" changes WITHOUT deleting newly-ignored files from working directory
#This will overwrite local tracked files with remote - ensure any local modifications are backed-up/stashed

git reset FETCH_HEAD

Сноски

¹ Поскольку это /.git/info/excludeможет быть применено ко всем историческим коммитам с использованием приведенных выше инструкций, возможно, подробности о том, как .gitignoreвставить файл в исторический коммит (ы), в которых он необходим, выходят за рамки этого ответа. Я хотел, чтобы собственное место .gitignoreбыло в корневом коммите, как будто это было первое, что я сделал. Другим это может не волновать, поскольку они /.git/info/excludeмогут выполнить одно и то же независимо от того, где они .gitignoreсуществуют в истории коммитов, и, очевидно, переписывание истории является очень деликатным вопросом, даже когда известно о последствиях .

FWIW, потенциальные методы могут включать git rebaseили git filter-branchкопировать внешнее .gitignore в каждый коммит, как ответы на этот вопрос

² Применение принудительного игнорирования поведения git после фиксации результатов автономной git rm --cachedкоманды может привести к удалению недавно игнорируемого файла при будущих извлечениях из пульта с принудительным нажатием. --prune-emptyФлаг в следующей git filter-branchкоманде позволяет избежать этой проблемы путем автоматического удаления предыдущего «удалить все игнорируемые файлы» индекс только совершить. Переписывание истории git также меняет хэши коммитов, что приведет к хаосу в будущих извлечениях из публичных / общих / совместных репозиториев. Пожалуйста, поймите все последствия, прежде чем делать это в таком репо. В этом руководстве GitHub указано следующее:

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

Альтернативными решениями, не влияющими на удаленное репо, являются git update-index --assume-unchanged </path/file>или git update-index --skip-worktree <file>, примеры которых можно найти здесь .

Если кто-то испытывает трудности с Windows, и вы хотите игнорировать всю папку, «cd», чтобы выбрать «папку» и выполните «Git Bash Here».

git ls-files -z | xargs -0 git update-index --assume-unchanged

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

git rm -r --cached **/*.lock

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

Надеюсь, что это помогает другим!