Удалите файл из Git, но не удаляйте его для удаленных пользователей, просто игнорируйте его.

Вы не можете.

Хм, позвольте мне попробовать еще раз: вы не можете, но они могут. Что ж, вы можете, но только для вас, а они могут, но только для них. Вы или они должны запустить git rm --cached в нужное время. Конечно, это решение, которое вы не хотите использовать.

Проще говоря (рискуя дублировать предыдущие вопросы): единственное, что вы можете сделать с этими файлами с точки зрения коммитов Git, - это исключить их из будущих коммитов Git. Не будучи в коммитах, они также не будут переданы операциями push и fetch.

Помните, что каждый коммит содержит полный и полный снимок всех файлов, о которых знает Git. (Мы немного уточним это через мгновение.) Если Git знает о .idea/*, Git поместит их в новых коммитах, и когда вы нажимаете эти коммиты - вы не можете нажимать файлы, только коммиты - эти коммиты вместе с этими файлами будут перемещаться. Когда вы получаете новые коммиты - опять же, вы получаете целые коммиты, а не файлы - эти коммиты приходят с этими файлами.

Тогда основная проблема становится такой:

• Вы или они находитесь в коммите, в котором Git знает о .idea/*. У вашего текущего коммита есть файлы.
• Вы или они получили новую фиксацию (и). Эти новые коммиты не содержат эти .idea/* файлы.
• Если вы (или они) теперь попросите ваш (или их) Git переключить вас с текущего коммита, на коммит, в котором отсутствуют файлы. , ваш (или их) Git видит, что вы (или они) явно указываете своему (их) Git удалить файлы. Так и будет.

Решение этой проблемы:

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

   git rm -r --cached .idea      # note the --cached
  

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

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

Лонг: что здесь происходит

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

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

Поскольку вы буквально не можете использовать эти файлы для выполнения какой-либо реальной работы, Git должен извлечь фиксацию. Это то, что делает git checkout (или, начиная с Git 2.23, git switch): он извлекает сублимированные файлы из некоторого коммита в форму, которую вы действительно можете использовать (и изменять). Фиксация, которую вы выбрали для извлечения, а затем работы и / или работы, является вашей текущей фиксацией.

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

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

Вместо этого Git хранит третью копию - ну, на самом деле не копию, потому что он использует лиофилизированный, дедуплицированный формат - в том, что Git называет своим < em> index, или staging area, или (редко в наши дни) cache. Эта кешированная, сублимированная, предварительно дедуплицированная копия файла в формате сублимационной сушки готова к использованию в следующей фиксации, которую вы сделаете.

Повторим это жирным шрифтом, потому что это ключ здесь: Индекс Git содержит файлы, которые войдут в следующую фиксацию в формате сублимационной сушки, готовые к работе. Операция git checkout или git switch заполняет индекс Git и ваше рабочее дерево из фиксации, которая теперь является текущей фиксацией. Все три копии теперь совпадают, за исключением того, что копию рабочего дерева можно использовать вместо сублимационной сушки.

Если вы измените копию рабочего дерева, вы должны запустить git add на нем. Команда git add сообщает Git: Сделайте так, чтобы ваша индексная копия соответствовала моей копии рабочего дерева. Git теперь будет читать копию рабочего дерева, сжимать и дедуплицировать ее в лиофилизированный формат < / em>, готов перейти к следующей фиксации. Таким образом, файлы в индексе больше не соответствуют файлам в текущей фиксации. Другими словами, ключевое различие между index и commit состоит в том, что вы можете изменять содержимое индекса, заменяя файлы оптом, как это.

git rm -r --cached .idea && git commit