Как сделать папку отслеживаемой в гит
Обновлено: 08.07.2024
Как сделать чтобы Git забыл о файле, который был отслежен, но теперь находится в .gitignore?
Тем не менее, этот файл продолжает отображаться в git status после его редактирования. Как вы заставляете git полностью забыть об этом? .gitignore предотвратит добавление неотслеживаемых файлов (без add -f) в набор файлов, отслеживаемых git, однако git продолжит отслеживать любые файлы, которые уже отслеживаются. Чтобы остановить отслеживание файла, вам необходимо удалить его из индекса. Это может быть достигнуто с помощью этой команды. Если вы хотите удалить всю папку, вам нужно рекурсивно удалить все файлы в ней. Удаление файла из заголовка ревизии произойдет при следующем коммите.
ВНИМАНИЕ Хотя это не удалит физический файл из вашего локального репозитория, он будет удалять файлы с машин других разработчиков при следующем git pull.
я клонировал проект, который включает в себя несколько .csproj файлы. Мне не нужно / как мой местный csproj файлы отслеживаются Git (или выводятся при создании патча), но, очевидно, они необходимы в проекте.
я добавил *.csproj внешний вид .gitignore , но файлы уже находятся в репозитории.
когда я набираю статус git, он показывает мои изменения в csproj который я не заинтересован в отслеживании или отправке патчей.
как я удалите "отслеживание" этих файлов из моего личного РЕПО (но держите их в источнике, чтобы я мог их использовать), чтобы я не видел изменений, когда я делаю статус (или создаю патч)?
звоню git rm --cached на каждом из файлов, которые вы хотите удалить из контроля версий, должно быть хорошо. Пока ваши локальные шаблоны игнорирования верны, вы не увидите эти файлы, включенные в вывод статуса git.
обратите внимание, что это решение удаляет файлы из репозитория, поэтому всем разработчикам необходимо будет поддерживать свои собственные локальные (не контролируемые ревизией) копии файла
чтобы предотвратить git от обнаружения изменений в этих файлах, вы также должны использовать эта команда:
что вы, вероятно, хотите сделать: (снизу @Ryan Taylor answer)
- это сказать git, что вы хотите свою собственную независимую версию файла или папки. Например, вы не хотите перезаписывать (или удалять) производственные / промежуточные файлы конфигурации.
Если у вас git update-index --assume-unchanged file.csproj , git не будет проверять файл.csproj для изменений автоматически: это остановит их появление в состоянии git при каждом их изменении. Так что можешь пометить все свои .файлы csproj таким образом-хотя вам придется вручную пометить любые новые, которые вышестоящий РЕПО отправляет вам. (Если они у вас есть в вашем .gitignore или .git/info/exclude , тогда те, которые вы создаете, будут проигнорированы)
Я не совсем уверен, что .файлы csproj есть. если они что-то вроде конфигураций IDE (аналогично Eclipse .затмение и. classpath files), то я бы предложил, чтобы они просто никогда не контролировались источником вообще. С другой стороны, если они являются частью системы сборки (например, Makefiles), то, очевидно, они должны--- и способ забрать дополнительные локальные изменения (например, из локального.csproj файл а-ля конфиг."МК") будет полезным: разделить, создать в глобальной частей и локальные переопределения.
это двухэтапный процесс:
удалить отслеживание файла / папки-но сохранить их на диске-с помощью
Теперь они не отображаются как "измененные", но все еще показывают как
добавлять их в .gitignore
1. это сохранит локальный файл для вас, но удалит его для кого-либо еще, когда они вытащат.
git rm --cached или git rm -r --cached
2. это для оптимизации, как папка с большим количеством файлов, например SDKs, которые, вероятно, никогда не изменится. Он говорит git прекратить проверять эту огромную папку каждый раз для изменений локально, так как у нее не будет никаких изменений. Этот assume-unchanged индекс будет сброшен и файл(ы) перезаписан, если есть изменения вверх по течению в файл/папку (когда вы тянете).
3. это сказать git, что вы хотите свою собственную независимую версию файла или папки. Например, вы не хотите перезаписывать (или удалять) производственные/промежуточные файлы конфигурации.
важно знать, что git update-index не распространяется С git, и каждый пользователь должен будет запустить его независимо.
принятый ответ все еще не работал для меня
git rm-r --кэшируется .
git добавить .
фиксация git commit-m".gitignore"
если у вас есть весь проект локально, но забыли добавить вас git игнорировать и теперь отслеживают некоторые ненужные файлы используйте эту команду, чтобы удалить все
убедитесь, что вы находитесь в корневом каталоге проекта.
тогда вы можете сделать обычный
добавить
фиксация
вывод
надеюсь, это поможет людям кто должен внести изменения в их .gitignore или забыл все это вместе.
- он удаляет весь кэш
- смотрит на свой .gitignore
- добавить файлы, которые вы хотите отслеживать
- толкает к вашему РЕПО
чтобы сэкономить время, правила, которые вы добавить в свой .gitignore может использоваться для удаления нескольких файлов / папок, т. е.
git rm --cached app/**/*.xml
git rm --cached -r app/widgets/yourfolder/
как указано в других ответах, выбранный ответ неверен.
на ответ на другой вопрос предполагает, что это может быть skip-worktree, который потребуется.
многие люди советуют вам использовать 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: Создайте первую версию этого класса, заполните поля, которые вы можете заполнить, и оставьте другие пустыми/null.
- 2: зафиксируйте и нажмите его на удаленный сервер.
- 3: git update-index --skip-worktree MySetupClass.java
- 4: обновите класс конфигурации с помощью собственных параметров.
- 5: вернуться работать над другой функциональностью.
изменения, которые вы делаете, будут следовать за вами независимо от ветви. Внимание: если ваши друзья также хотят изменить этот класс, они должны иметь ту же настройку, иначе их изменения будут перенесены в удаленный репозиторий. При вытягивании удаленная версия файла должна перезаписать вашу.
PS: сделайте то или другое, но не оба, так как у вас будут нежелательные побочные эффекты. Если вы хотите попробовать другой флаг, сначала вы должны отключить последнее.
есть файл, который отслеживается git , но теперь файл находится на .gitignore список.
однако этот файл продолжает отображаться в git status после редактирования. Как вы заставляете git чтобы совсем забыть об этом?
.gitignore позволит предотвратить неотслеживаемые файлы могут быть добавлены (без add -f ) к набору файлов, отслеживаемых git, однако git будет продолжать отслеживать любые файлы, которые уже отслеживаются.
чтобы остановить отслеживание файла, необходимо удалить его из индекса. Это может быть достигнуто с помощью этой команды.
удаление файла из Главной редакции произойдет при следующем коммите.
серия команд ниже удалит все элементы из индекса Git (не из рабочего каталога или локального РЕПО), а затем обновит индекс Git, соблюдая при этом git игнорирует. PS. Index = Cache
первый:
затем:
Это принимает список игнорируемых файлов и удаляет их из индекса, а затем вносятся изменения.
Я всегда использую эту команду, чтобы удалить эти неотслеживаемые файлы. Однострочный, Unix-стиль, чистый вывод:
он перечисляет все ваши игнорируемые файлы, заменяет каждую выходную строку на строку в кавычках вместо того, чтобы обрабатывать пути с пробелами внутри, и передает все в git rm -r --cached чтобы удалить пути / файлы / dirs из индекса.
- ваш приложения для игнорируемых файлов конфигурации-высшую.ini и использовать более совершенные файл config.ini (или поочередно, ищите~/.config / myapp.ini, или $MYCONFIGFILE)
- Commit file config-sample.ini и игнорировать файл config.ini, есть скрипт или аналогичная копия файла по мере необходимости, если это необходимо.
- попробуйте использовать gitattributes clean/smudge magic, чтобы применить и удалить изменения для вас, например смазать файл конфигурации в качестве проверки из альтернативной ветви и очистить файл конфигурации как проверка от головы. Это сложный материал, я не рекомендую его для начинающего пользователя.
- сохраните файл конфигурации в ветке развертывания, выделенной для него, которая никогда не объединяется с master. Когда вы хотите развернуть / скомпилировать / протестировать, вы сливаетесь с этой ветвью и получаете этот файл. Это, по сути, грязный / чистый подход, за исключением использования политик слияния людей и дополнительных модулей git.
- Anti-recommentation: не используйте assume-unchanged, это закончится только слезами.
переместить его, зафиксировать, а затем переместить его обратно. Это работало для меня в прошлом. Вероятно, есть более "хитрый" способ добиться этого.
что не сработало для меня
поэтому я предлагаю
использует до ls-files и
Я сделал это с помощью git filter-branch. Точная команда, которую я использовал, была взята из man-страницы:
предупреждение: это приведет к удалению файла из всей вашей истории
эта команда воссоздаст всю историю фиксации, выполнив git rm перед каждой фиксацией и так избавится от указанного файла. Не забудьте создать резервную копию перед запуском команды как это будет будут потеряны.
допустим, вы уже добавили/зафиксировали некоторые файлы в свой репозиторий git, а затем добавили их в свой .гитюдного; эти файлы будут по-прежнему присутствовать в ваш индекс репозитория. В этой статье мы увидим, как от них избавиться.
Шаг 1: зафиксируйте все ваши изменения
прежде чем продолжить, убедитесь, что все ваши изменения зафиксированы, включая ваши .файла.gitignore
Шаг 2: Удалите все из репозитория
чтобы очистить РЕПО, используйте:
- rm это команда удалить
- - r позволит рекурсивный удаление
- - cached будут удалены только файлы из индекса. Ваши файлы все еще будут там.
The rm команда может быть неумолимой. Если вы хотите попробовать то, что он делает заранее, добавить -n или --dry-run флаг, чтобы проверить вещи.
Шаг 3: Re добавить все
Шаг 4: Commit
ваш репозиторий чистые :)
нажмите изменения на пульте дистанционного управления, чтобы увидеть изменения действуют и там.
обновить .gitignore file-например, добавьте папку, которую вы не хотите отслеживать в .gitignore .
git rm -r --cached . - удалить все отслеживаемые файлы, в том числе разыскиваемые и нежелательные. Ваш код будет в безопасности, пока вы сохранили локально.
git add . – все файлы будут добавлены обратно, за исключением .gitignore .
Я думаю, что, возможно, git не может полностью забыть о файле из-за его концепции (раздел "снимки, а не различия").
эта проблема отсутствует, например, при использовании CVS. CVS хранит информацию в виде списка изменений на основе файлов. Информация для CVS представляет собой набор файлов и изменений, внесенных в каждый файл с течением времени.
но в Git каждый раз, когда вы совершаете или сохраняете состояние своего проекта, он в основном делает снимок того, что все ваши файлы выглядеть в этот момент и сохраняет ссылку на этот снимок. Поэтому, если вы добавили файл один раз, он всегда будет присутствовать в этом снимке.
эти 2 статьи были полезны для меня:
git предположим-без изменений против skip-worktree и как игнорировать изменения в отслеживаемых файлах с Git
исходя из этого я делаю следующее, если файл уже отслеживается:
от в этот момент все локальные изменения в этом файле будут проигнорированы и не перейдут на удаленный. Если файл изменяется на удаленном, конфликт произойдет, когда git pull . Тайник не сработает. Чтобы решить ее, скопируйте содержимое файла в безопасное место и выполните следующие действия:
содержимое файла будет заменено удаленным содержимым. Вставьте изменения из безопасного места в файл и выполните еще раз:
если все, кто работает с проектом, будет выполнять git update-index --skip-worktree , проблемы с pull должен отсутствовать. Это решение подходит для файлов конфигураций, когда каждый разработчик имеет свою собственную конфигурацию проекта.
это не очень удобно делать каждый раз, когда файл был изменен на удаленном, но может защитить его от перезаписи удаленным контентом.
переместить или скопировать файл в безопасном месте, так что вы не потеряете его. Затем git rm файл и фиксация. Файл по-прежнему будет отображаться, если вы вернетесь к одному из этих предыдущих коммитов или другой ветви, где он не был удален. Однако во всех последующих коммитах вы больше не увидите этот файл. Если файл находится в Git ignore, вы можете переместить его обратно в папку, и git не увидит его.
ответ от Мэтта страха был самым эффективным ИМХО. Ниже приведен только сценарий PowerShell для тех, кто в windows, чтобы удалить только файлы из своего репозитория git, который соответствует их списку исключений.
Если вы не хотите использовать CLI и работаете в Windows, очень простое решение-использовать TortoiseGit, Он имеет действие "удалить (сохранить локальный)" в меню, которое отлично работает.
Существует файл, который отслеживается git , но теперь файл находится в списке .gitignore .
Тем не менее, этот файл продолжает отображаться в git status после его редактирования. Как вы заставляете git полностью забыть об этом?
ОТВЕТЫ
Ответ 1
.gitignore предотвратит добавление неотслеживаемых файлов (без add -f ) в набор файлов, отслеживаемых git, однако git продолжит отслеживать любые файлы, которые уже отслеживаются.
Чтобы остановить отслеживание файла, вам необходимо удалить его из индекса. Это может быть достигнуто с помощью этой команды.
Если вы хотите удалить всю папку, вам нужно рекурсивно удалить все файлы в ней.
Удаление файла из заголовка ревизии произойдет при следующем коммите.
ВНИМАНИЕ: Хотя это не удалит физический файл из вашего локального, он будет удалять файлы с машин других разработчиков при следующем git pull .
Ответ 2
В приведенной ниже последовательности команд будут удалены все элементы из индекса Git (не из рабочего каталога или локального репо), а затем обновляется индекс Git, при этом игнорируется Git. PS. Index = Кэш
Во-первых:
Тогда:
Ответ 3
git update-index делает всю работу за меня:
Примечание. Это решение фактически не зависит от .gitignore как gitignore предназначен только для неотслеживаемых файлов.
Ответ 4
Это берет список игнорируемых файлов и удаляет их из индекса, а затем фиксирует изменения.
Ответ 5
Я всегда использую эту команду для удаления этих невоспроизводимых файлов. Однострочный, Unix-стиль, чистый вывод:
В нем перечислены все ваши проигнорированные файлы, вместо каждой строки вывода заменена линией с кавычками, чтобы обрабатывать пути с пробелами внутри и передавать все в git rm -r --cached , чтобы удалить пути/файлы/директории из индекса.
Ответ 6
переместите его, зафиксируйте, а затем верните его. Это сработало для меня в прошлом. Вероятно, есть способ "gittier" выполнить это.
Ответ 7
- Попросите ваше приложение найти пропущенный файл config-overide.ini и использовать его поверх зафиксированного файла config.ini (или, альтернативно, найдите ~/.config/myapp.ini или $ MYCONFIGFILE)
- Зафиксируйте файл config-sample.ini и проигнорируйте файл config.ini, при необходимости создайте скрипт или аналогичный файл для копирования.
- Попробуйте применить магию gitattributes clean/smudge для применения и удаления изменений, например, размазать файл конфигурации как извлечение из альтернативной ветки и очистить файл конфигурации как извлечение из HEAD. Это сложная штука, я не рекомендую ее для начинающего пользователя.
- Сохраните файл конфигурации в выделенной для него ветке развертывания, которая никогда не объединяется с master. Когда вы хотите развернуть/скомпилировать/протестировать, вы сливаетесь с этой веткой и получаете этот файл. По сути, это подход smudge/clean, за исключением использования политик слияния людей и дополнительных git-модулей.
- Антирекомендация: не используйте предположения без изменений, это закончится только слезами (потому что ложная ложь сама по себе приведет к плохим вещам, таким как ваши изменения будут потеряны навсегда).
Ответ 8
Допустим, вы уже добавили/перенесли некоторые файлы в свой репозиторий git, а затем добавили их в свой.gitignore; эти файлы все равно будут присутствовать в вашем индексе репозитория. В этой статье мы увидим, как избавиться от них.
Шаг 1: Зафиксируйте все свои изменения
Прежде чем продолжить, убедитесь, что все ваши изменения зафиксированы, включая файл.gitignore.
Шаг 2. Удалите все из хранилища.
Чтобы очистить свое репо, используйте:
- rm - команда удаления
- -r позволит рекурсивное удаление
- -Cached будет удалять только файлы из индекса. Ваши файлы все равно будут там.
Команда rm может быть неумолимой. Если вы хотите попробовать, что он делает заранее, добавьте -n или --dry-run чтобы проверить все.
Шаг 3: добавьте все
Шаг 4: Зафиксировать
Ваш репозиторий чист :)
Нажмите на изменения на пульте дистанционного управления, чтобы увидеть изменения, которые там также эффективны.
Ответ 9
Я сделал это, используя git ветвь фильтра. Точная команда, которую я использовал, была взята с man-страницы:
ПРЕДУПРЕЖДЕНИЕ: это приведет к удалению файла из всей истории
Эта команда воссоздает всю историю фиксации, выполнив git rm перед каждой фиксацией и таким образом избавится от указанного файла. Не забудьте выполнить резервное копирование перед запуском команды, поскольку она будет потеряна.
Ответ 10
Что не сработало для меня
Поэтому я предлагаю
Это использует аргумент -z для ls-files, а аргумент -0 - xargs, чтобы безопасно/корректно использовать для "неприятных" символов в именах файлов.
На странице руководства git -ls-files (1) указано:
Если параметр -z не используется, символы TAB, LF и обратная косая черта в pathnames представлены как \t,\n и\\соответственно.
поэтому я думаю, что мое решение необходимо, если в именах файлов есть какие-либо из этих символов.
EDIT: меня попросили добавить, что --- как и любая команда git rm - за ней должен следовать commit, чтобы сделать удаление перманентным, например. git commit -am "Remove ignored files" .
Ответ 11
Обновите файл .gitignore - например, добавьте папку, в которую вы не хотите отслеживать .gitignore .
git rm -r --cached . - удалить все отслеженные файлы, включая нежелательные и нежелательные. Ваш код будет безопасным, если вы сохранили его локально.
git add . - все файлы будут добавлены обратно, кроме тех, что указаны в .gitignore .
Совет шляпы @AkiraYamamoto для указания в правильном направлении.
Ответ 12
Я думаю, что, возможно, git не может полностью забыть о файле из-за его концепции (раздел "Снимки, а не разницы" ).
Эта проблема отсутствует, например, при использовании CVS. CVS хранит информацию как список изменений на основе файлов. Информация для CVS представляет собой набор файлов и изменений, внесенных в каждый файл с течением времени.
Но в git каждый раз, когда вы совершаете фиксацию или сохраняете состояние своего проекта, в нем в основном делается фотография того, что все ваши файлы выглядят в данный момент и хранит ссылку на этот снимок, Итак, если вы добавили файл один раз, он всегда будет присутствовать в этом снимке.
Эти 2 статьи были полезны для меня:
Основываясь на этом, я делаю следующее, если файл уже отслеживается:
С этого момента все локальные изменения в этом файле будут проигнорированы и не будут удалены. Если файл изменен на удаленном, конфликт будет иметь место, когда git pull . Стой не будет работать. Чтобы решить проблему, скопируйте содержимое файла в безопасное место и выполните следующие действия:
Содержимое файла будет заменено удаленным контентом. Вставьте свои изменения из безопасного места в файл и выполните снова:
Если каждый, кто работает с проектом, выполнит git update-index --skip-worktree , проблемы с pull должны отсутствовать. Это решение подходит для файлов конфигураций, когда каждый разработчик имеет собственную конфигурацию проекта.
Это не очень удобно делать каждый раз, когда файл был изменен на удаленном компьютере, но может защитить его от перезаписи удаленным контентом.
Ответ 13
Делайте следующие шаги поочередно, у вас все будет хорошо.
1. удалить ошибочно добавленные файлы из каталога/хранилища. Вы можете использовать команду "rm -r" (для linux) или удалить их, просматривая каталоги. Или переместите их в другое место на вашем ПК. [Возможно, вам придется закрыть IDE, если вы хотите переместить/удалить ]
2. добавьте файлы/каталоги в файл gitignore и сохраните его.
3. Теперь удалите их из кеша git с помощью этих команд (если существует более одного каталога, удалите их один за другим, повторно выполнив эту команду)
4. Теперь сделайте коммит и нажмите, используйте эти команды. Это удалит эти файлы из git remote и заставит git перестать отслеживать эти файлы.
Ответ 14
Ответ копирования/вставки: git rm --cached -r.; git add.; git status git rm --cached -r.; git add.; git status
Эта команда будет игнорировать файлы, которые уже были переданы в репозиторий Git, но теперь мы добавили их в .gitignore .
Ответ 15
Ответ от Matt Fear был самым эффективным IMHO. Следующее - это просто PowerShell script для тех, кто в Windows только удаляет файлы из своего репозитория git, который соответствует их списку исключений.
Ответ 16
Переместите или скопируйте файл в безопасное место, чтобы вы не потеряли его. Затем git rm файл и commit. Файл будет отображаться, если вы вернетесь к одному из этих ранее коммитов, или к другой ветке, где она не была удалена. Однако во всех будущих коммитах вы не увидите файл снова. Если файл находится в git игнорировать, вы можете переместить его обратно в папку, а git не увидит его.
Ответ 17
BFG специально разработан для удаления нежелательных данных, таких как большие файлы или пароли из репозиториев Git, поэтому он имеет простой флаг, который удалит любые большие исторические файлы (не в вашем-текущем): "-strip-blobs-больше-чем"
Если вы хотите указать файлы по имени, вы также можете это сделать:
BFG на 10-1000x быстрее, чем Git фильтр-ветвь, и, как правило, гораздо проще в использовании - проверьте инструкции для полного использования и examples для более подробной информации.
Ответ 18
Если вы не хотите использовать CLI и работаете с Windows, очень простое решение - использовать TortoiseGit, у него есть действие "Удалить (сохранить локальное)" в меню, которое работает нормально.
Ответ 19
Мне понравился ответ 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 и удалить проигнорированные файлы из индекса"
- удалить проигнорированные файлы из индекса
- stage.gitignore и файлы, которые вы только что удалили.
- совершить
Ответ 20
Использование команды git rm --cached не отвечает на исходный вопрос:
Как вы заставляете git полностью забыть о [файле]?
Фактически, это решение приведет к удалению файла во всех остальных экземплярах хранилища при выполнении git pull !
Правильный способ заставить git забыть о файле задокументирован здесь GitHub.
Я рекомендую прочитать документацию, но в основном:
просто замените full/path/to/file на полный путь к файлу. Убедитесь, что вы добавили файл в свой .gitignore .
Вам также нужно (временно) разрешить не-ускоренные пересылки в ваш репозиторий, так как вы изменяете свою историю git.
Ответ 21
Это уже не проблема в последнем git (v2.17.1 на момент написания).
В .gitignore игнорирует файлы с отслеживанием, но удаленные. Вы можете проверить это самостоятельно, выполнив следующий сценарий. Окончательное выражение о git status должно сообщать "ничего не делать".
Ответ 22
В случае уже совершенного DS_Store :
Наконец, сделайте фиксацию!
Ответ 23
Специально для файлов на основе IDE, я использую это:
Например, slnx.sqlite, я просто полностью избавился от него следующим образом:
Просто имейте в виду, что некоторые из этих файлов хранят некоторые локальные пользовательские настройки и предпочтения для проектов (например, какие файлы у вас были открыты). Таким образом, каждый раз, когда вы перемещаетесь или делаете какие-либо изменения в вашей IDE, этот файл изменяется, и поэтому он проверяет его и показывает, что есть незафиксированные изменения.
Ответ 24
Принятый ответ не "заставляет Git " забывать " о файле. " (исторически). Это только заставляет git игнорировать файл в настоящем/будущем.
Этот метод заставляет git полностью забывать игнорируемые файлы (прошлое/настоящее/будущее), но не не удаляет что-либо из рабочего каталога (даже при повторном извлечении из удаленного).
Этот метод требует использования /.git/info/exclude (предпочтительно) ИЛИ ранее pre-existing .gitignore во всех коммитах, в которых есть файлы, которые должны быть проигнорированы/забыты. 1
Все методы принудительного применения git игнорируют поведение после факта, эффективно переписывают историю и, таким образом, имеют значительные последствия для любых публичных/общих/совлокальных репозиториев, которые могут быть извлечены после этого процесса. 2
Общий совет: начните с чистого репо - все зафиксировано, ничего не ожидает в рабочем каталоге или индексе, и сделайте резервную копию!
Also, the comments/revision history of this answer (and revision history of this question) may be useful/enlightening.
Наконец, следуйте остальной части этого руководства по GitHub (начиная с шага 6) , в котором содержатся важные предупреждения/сведения о командах ниже.
Другие разработчики, которые используют измененное удаленное хранилище, должны создать резервную копию, а затем:
Сноски
1 Поскольку /.git/info/exclude можно применять ко всем историческим коммитам, используя приведенные выше инструкции, возможно, подробности о получении файла .gitignore в исторические коммиты, которые нуждаются в нем, выходят за рамки этого ответа. Я хотел, чтобы .gitignore был в корневом коммите, как будто это было первое, что я сделал. Другие могут не заботиться, так как /.git/info/exclude может выполнить одно и то же, независимо от того, где .gitignore существует в истории коммитов, и ясно, что переписывание истории является очень раздражающим предметом, даже когда известно о последствия.
Кстати, потенциальные методы могут включать в себя git rebase или git filter-branch , который копирует внешний .gitignore в каждый коммит, как ответы на этот вопрос
2 Принудительное поведение git ignore после фиксации результатов автономной команды git rm --cached может привести к тому, что delete вновь игнорируется файл в будущем при извлечении из пульта с принудительным нажатием. Флаг --prune-empty в следующей команде git filter-branch позволяет избежать этой проблемы, автоматически удаляя предыдущую фиксацию только для индекса "удалить все игнорируемые файлы". Переписывание истории git также меняет хэши коммитов, которые нанесут ущерб будущим извлечениям из публичных/общих/совлокальных репозиториев. Пожалуйста, полностью поймите последствия, прежде чем делать это с таким репо. В этом руководстве по GitHub указано следующее:
Скажите вашим соавторам перебазировать, а не объединять любые ветки, которые они создали из вашей старой (испорченной) истории репозитория. Одна фиксация слияния может восстановить некоторые или всю испорченную историю, которую вы только что очистили.
Альтернативными решениями, которые не влияют на удаленное репо, являются git update-index --assume-unchanged
или git update-index --skip-worktree , примеры которых можно найти здесь.
Ответ 25
1. Удалите файлы DS_Store из списка файлов, отслеживаемых git в ветке foo:
Читайте также: