Git, как удалить файлы из отслеживания

Обновлено: 21.11.2024

Нахождение быстрого решения типичных проблем в git remove file from tracking улучшит ваш опыт управления программным обеспечением. Это позволяет с легкостью устранить проблемы с push- и pull-запросами.

Сценарий-1

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

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

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

Сценарий-2

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

Лучшая команда для использования в данных обстоятельствах

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

Сценарий-3

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

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

Настройка лабораторной среды

Я создаю удаленное хранилище под названием remove_from_tracking на Github.

Возьмите URL-адрес клона.

Перейдите к терминалу или командной строке и клонируйте репозиторий в локальный каталог с именем golinux .

перейдите в клонированный репозиторий, remove_from_tracking .

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

Пример-1: git удалить файл из отслеживания, не удаляя его

Давайте продолжим создание репозитория, готового к отслеживанию файлов.

Проверить отслеживаемые файлы с помощью команды

В настоящее время отслеживается только один файл, README.md.

Давайте создадим еще два файла, file1.txt и file2.txt .

показывает, что два файла не отслеживаются.

Давайте подготовим неотслеживаемые файлы

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

показывает, что мы отслеживаем три файла: README.md , file1.txt и file2.txt .

Предположим, мы решили отменить отслеживание file2.txt . Мы можем git удалить файл из отслеживания, выполнив команду:

для проверки отслеживаемых файлов.

показывает, что file2.txt теперь не отслеживается.

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

Чтобы убедиться, что команда git rm --cached не изменяет рабочую область, откройте файл с помощью редактора кода или выведите список файлов и каталогов с помощью команды

в папке remove_from_tracking.

Бонусный трюк

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

Вот команда для отмены отслеживания и удаления файла из рабочего каталога:

Давайте применим это.

снова создать файл file2.txt, а затем зафиксировать его, запустив

подтвердить, что мы снова отслеживаем файл file2.txt.

Удалить файл из списка отслеживания с помощью этой короткой команды

в командной строке.

Что вы заметили?

Использование команды

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

Пример 2: git удаляет файл из отслеживания и решает проблемы с игнорированием

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

На данный момент мы отслеживаем два файла: README.md и file1.txt .

Создайте файл test.py и добавьте в него новую строку.

git добавить . , git commit -m "случайно отслежен пароль" и git поместите его в удаленный репозиторий, который вы создали в начале этого руководства.

Проверьте содержимое файла test.py в удаленном репозитории. Любой может увидеть наш пароль.

Давайте git удалим файл из отслеживания, создав файл .gitignore и сославшись на файл test.py в нем.

Отслеживайте изменения.

Проверить отслеживаемые файлы.

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

Давайте удалим его из области отслеживания

и проверьте изменения.

test.py отсутствует в отслеживаемых файлах, но по-прежнему упоминается в .gitignore .

Давайте также обновим удаленное хранилище.

В удаленном репозитории отсутствует файл test.py.

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

Пример 3. Удаление файла из списка отслеживания из всех запросов на вытягивание git

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

Предположим, мы хотим удалить README.md из отслеживания. Мы можем запустить эту команду:

если мы не изменим файл или он займет много места для хранения.

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

Пример 4: Удалить весь каталог из отслеживания в git

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

Вернитесь к терминалу или командной строке и создайте папку html_files .

перейдите в папку html_files и добавьте два файла, index.html и about.html .

Перейдите в родительскую папку, remove_from_tracking .

показывает, что теперь мы отслеживаем index.html и about.html .

Позже мы поняли, что не будем работать с HTML. Поэтому мы хотим отменить отслеживание файлов index.html и about.html, а затем удалить их.

Мы можем отменить отслеживание папки, выполнив эту однострочную команду:

Повторно проверьте отслеживаемые файлы.

Не забудьте поставить косую черту \ перед звездочкой *, чтобы выйти из команды git commit. Теперь наши файлы не отслеживаются и лежат на жестком диске.

После отмены отслеживания файлов мы можем удалить их, выполнив команду

Заключение

Понимание и применение git remove file из отслеживания улучшит ваш личный опыт и упростит взаимодействие в команде при работе с файлами. Теперь, когда вы знаете, почему, когда и как удалять файлы из списка отслеживания, приступайте к процессу отслеживания файлов.

Похожие записи

Не нашли то, что искали? Выполните быстрый поиск в GoLinuxCloud

Если мои статьи о GoLinuxCloud помогли вам, пожалуйста, купите мне кофе в знак признательности.

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

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

Помните, что каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: отслеживается или не отслеживается. Отслеживаемые файлы — это файлы, которые были в последнем моментальном снимке, а также любые недавно подготовленные файлы; они могут быть немодифицированными, модифицированными или поэтапными. Короче говоря, отслеживаемые файлы — это файлы, о которых Git знает.

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

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

Проверка статуса ваших файлов

Основной инструмент, который вы используете для определения того, в каком состоянии находятся файлы, — это команда git status. Если вы запустите эту команду сразу после клона, вы должны увидеть что-то вроде этого:

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

Допустим, вы добавили в проект новый файл, простой файл README. Если файла раньше не существовало, и вы запускаете git status , вы видите свой неотслеживаемый файл следующим образом:

Вы можете видеть, что ваш новый файл README не отслеживается, потому что он находится под заголовком «Неотслеживаемые файлы» в выводе статуса. Неотслеживаемый в основном означает, что Git видит файл, которого у вас не было в предыдущем моментальном снимке (фиксации) и который еще не был подготовлен; Git не начнет включать его в ваши снимки коммитов, пока вы явно не скажете ему об этом. Это делается для того, чтобы вы случайно не начали включать сгенерированные двоичные файлы или другие файлы, которые вы не хотели включать. Вы действительно хотите включить README , так что давайте начнем отслеживать файл.

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

Чтобы начать отслеживать новый файл, используйте команду git add . Чтобы начать отслеживать файл README, вы можете запустить это:

Если вы снова запустите команду состояния, вы увидите, что ваш файл README теперь отслеживается и готовится к фиксации:

Вы можете сказать, что это постановочное, потому что оно находится под заголовком «Изменения, которые необходимо зафиксировать». Если вы зафиксируете в этот момент, версия файла на момент запуска git add будет такой же, как и в последующем историческом моментальном снимке. Вы можете вспомнить, что когда вы запускали git init ранее, вы затем запускали git add — это должно было начать отслеживать файлы в вашем каталоге. Команда git add принимает путь либо к файлу, либо к каталогу; если это каталог, команда рекурсивно добавляет все файлы в этом каталоге.

Подготовка измененных файлов

Давайте изменим уже отслеженный файл. Если вы измените ранее отслеживаемый файл с именем CONTRIBUTING.md, а затем снова запустите команду git status, вы получите что-то вроде этого:

Файл CONTRIBUTING.md отображается в разделе «Изменения, не подготовленные для фиксации». Это означает, что отслеживаемый файл был изменен в рабочем каталоге, но еще не подготовлен. Чтобы подготовить его, вы запускаете команду git add. git add — это многоцелевая команда — вы используете ее, чтобы начать отслеживать новые файлы, создавать файлы и выполнять другие действия, например, помечать файлы, конфликтующие слиянием, как разрешенные.Может быть полезно думать об этом больше как о «добавлении именно этого содержимого к следующему коммиту», а не о «добавлении этого файла в проект». Давайте сейчас запустим git add, чтобы подготовить файл CONTRIBUTING.md, а затем снова запустим git status:

Оба файла находятся в промежуточном состоянии и войдут в вашу следующую фиксацию. Теперь предположим, что вы помните одно маленькое изменение, которое хотите внести в CONTRIBUTING.md перед его фиксацией. Вы открываете его снова и вносите это изменение, и вы готовы зафиксировать. Однако давайте еще раз запустим git status:

Какого черта? Теперь CONTRIBUTING.md указан и как поэтапный и как неустановленный. Как это возможно? Оказывается, Git размещает файл точно так же, как когда вы запускаете команду git add. Если вы сделаете коммит сейчас, версия CONTRIBUTING.md, которая была, когда вы в последний раз запускали команду git add, будет использоваться в коммите, а не версия файла, как он выглядит в вашем рабочем каталоге, когда вы запускаете git commit . Если вы изменяете файл после запуска git add , вам нужно запустить git add еще раз, чтобы подготовить последнюю версию файла:

Краткий статус

Несмотря на то, что вывод состояния git довольно полный, он также довольно многословен. Git также имеет краткий флаг состояния, чтобы вы могли видеть свои изменения в более компактном виде. Если вы запустите git status -s или git status --short, вы получите гораздо более упрощенный вывод команды:

Новые файлы, которые не отслеживаются, помечаются знаком ?? рядом с ними новые файлы, которые были добавлены в промежуточную область, имеют A , измененные файлы имеют M и так далее. На выходе есть два столбца: левый столбец указывает состояние промежуточной области, а правый столбец указывает состояние рабочего дерева. Так, например, в этом выводе файл README изменен в рабочем каталоге, но еще не подготовлен, а файл lib/simplegit.rb изменен и подготовлен. Rakefile был изменен, подготовлен и затем изменен снова, поэтому в нем есть изменения, которые являются как подготовленными, так и неустановленными.

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

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

Первая строка указывает Git игнорировать любые файлы, оканчивающиеся на «.o» или «.a» — объектные и архивные файлы, которые могут быть результатом сборки вашего кода. Вторая строка указывает Git игнорировать все файлы, имена которых заканчиваются на тильду ( ~ ), которая используется многими текстовыми редакторами, такими как Emacs, для пометки временных файлов. Вы также можете включить каталог log, tmp или pid; автоматически формируемая документация; и так далее. Настроить файл .gitignore для вашего нового репозитория перед тем, как вы начнете, как правило, хорошая идея, чтобы вы случайно не зафиксировали файлы, которые вам действительно не нужны в вашем репозитории Git.

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

Стандартные шаблоны глобусов работают и будут применяться рекурсивно ко всему рабочему дереву.

Вы можете начинать шаблоны с косой черты ( / ), чтобы избежать рекурсии.

Вы можете заканчивать шаблоны косой чертой ( / ), чтобы указать каталог.

Вы можете отменить шаблон, начав его с восклицательного знака ( ! ).

Шаблоны Glob похожи на упрощенные регулярные выражения, используемые оболочками. Звездочка ( * ) соответствует нулю или более символов; [abc] соответствует любому символу в квадратных скобках (в данном случае a, b или c); знак вопроса ( ? ) соответствует одному символу; а скобки, заключающие символы, разделенные дефисом (9), соответствуют любому символу между ними (в данном случае от 0 до 9). Вы также можете использовать две звездочки для соответствия вложенным каталогам; a/**/z будет соответствовать a/z , a/b/z , a/b/c/z и т. д.

Вот еще один пример файла .gitignore:

В простом случае репозиторий может иметь один файл .gitignore в корневом каталоге, который рекурсивно применяется ко всему репозиторию. Однако также возможно иметь дополнительные файлы .gitignore в подкаталогах. Правила в этих вложенных файлах .gitignore применяются только к файлам в каталоге, в котором они расположены. Репозиторий исходного кода ядра Linux содержит 206 файлов .gitignore.

В задачу этой книги не входит детальное рассмотрение нескольких файлов .gitignore; подробности см. в man gitignore.

Просмотр поэтапных и неустановленных изменений

Если команда git status кажется вам слишком расплывчатой — вы хотите точно знать, что вы изменили, а не только то, какие файлы были изменены, — вы можете использовать команду git diff. Мы рассмотрим git diff более подробно позже, но вы, вероятно, будете использовать его чаще всего, чтобы ответить на эти два вопроса: что вы изменили, но еще не проиндексировали? И что вы инсценировали, что собираетесь совершить?Хотя git status отвечает на эти вопросы в общих чертах, перечисляя имена файлов, git diff показывает вам точные добавленные и удаленные строки — так сказать, патч.

Допустим, вы снова отредактировали и подготовили файл README, а затем отредактировали файл CONTRIBUTING.md, не подготовив его. Если вы запустите команду git status, вы снова увидите что-то вроде этого:

Чтобы увидеть, что вы изменили, но еще не подготовили, введите git diff без других аргументов:

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

Если вы хотите увидеть, что вы подготовили для следующего коммита, вы можете использовать git diff --staged . Эта команда сравнивает ваши поэтапные изменения с вашей последней фиксацией:

Важно отметить, что git diff сам по себе не показывает все изменения, сделанные с момента вашего последнего коммита, а только те изменения, которые еще не подготовлены. Если вы подготовили все свои изменения, git diff ничего не выдаст.

Для другого примера, если вы подготовите файл CONTRIBUTING.md, а затем отредактируете его, вы можете использовать git diff, чтобы увидеть изменения в файле, которые были подготовлены, и изменения, которые не были подготовлены. Если наша среда выглядит так:

Теперь вы можете использовать git diff, чтобы увидеть, что еще не обработано:

и git diff --cached, чтобы увидеть, что вы подготовили на данный момент ( --staged и --cached являются синонимами):

Мы продолжим использовать команду git diff различными способами в оставшейся части книги. Есть еще один способ посмотреть на эти различия, если вместо этого вы предпочитаете графическую или внешнюю программу просмотра различий. Если вы запустите git difftool вместо git diff , вы сможете просматривать любые из этих различий в таких программах, как emerge, vimdiff и многих других (включая коммерческие продукты). Запустите git difftool --tool-help, чтобы узнать, что доступно в вашей системе.

Фиксация ваших изменений

Теперь, когда ваша тестовая область настроена так, как вы хотите, вы можете зафиксировать свои изменения. Помните, что все, что еще не проиндексировано — любые созданные или измененные вами файлы, которые вы не запускали с помощью git add с тех пор, как вы их редактировали, — не войдет в эту фиксацию. Они останутся в виде измененных файлов на вашем диске. В этом случае предположим, что когда вы в последний раз запускали git status , вы видели, что все было подготовлено, поэтому вы готовы зафиксировать свои изменения. Самый простой способ зафиксировать — набрать git commit :

При этом запускается выбранный вами редактор.

Это задается переменной среды EDITOR вашей оболочки — обычно это vim или emacs, хотя вы можете настроить его как угодно, используя команду git config --global core.editor, как вы видели в разделе «Начало работы».

В редакторе отображается следующий текст (в этом примере показан экран Vim):

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

Для еще более явного напоминания о том, что вы изменили, вы можете передать параметр -v в git commit . При этом в редакторе также отображается разница ваших изменений, чтобы вы могли точно видеть, какие изменения вы вносите.

Когда вы выходите из редактора, Git создает вашу фиксацию с этим сообщением фиксации (с удаленными комментариями и различиями).

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

Теперь вы создали свой первый коммит! Вы можете видеть, что фиксация предоставила вам некоторую информацию о себе: какую ветку вы зафиксировали ( master ), какую контрольную сумму SHA-1 имеет фиксация ( 463dc4f ), сколько файлов было изменено и статистику о строках, добавленных и удаленных в зафиксировать.

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

Пропуск области подготовки

Хотя это может быть удивительно полезно для создания коммитов именно так, как вы хотите, область подготовки иногда немного сложнее, чем вам нужно в вашем рабочем процессе. Если вы хотите пропустить промежуточную область, Git предоставляет простой ярлык. Добавление параметра -a к команде git commit заставляет Git автоматически публиковать каждый файл, который уже отслежен, перед выполнением фиксации, позволяя вам пропустить часть git add:

Обратите внимание, что в этом случае вам не нужно запускать git add для файла CONTRIBUTING.md перед фиксацией. Это потому, что флаг -a включает все измененные файлы. Это удобно, но будьте осторожны; иногда этот флаг заставит вас включить нежелательные изменения.

Удаление файлов

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

Если вы просто удалите файл из своего рабочего каталога, он появится в области «Изменения, не подготовленные для фиксации» (то есть не подготовленные) вашего вывода статуса git:

Затем, если вы запустите git rm , он поэтапно удалит файл:

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

Еще одна полезная вещь, которую вы можете сделать, это оставить файл в рабочем дереве, но удалить его из области подготовки. Другими словами, вы можете захотеть сохранить файл на жестком диске, но Git больше не будет его отслеживать. Это особенно полезно, если вы забыли добавить что-то в свой файл .gitignore и случайно подставили его, например, большой файл журнала или кучу скомпилированных файлов .a. Для этого используйте параметр --cached:

Команде git rm можно передавать файлы, каталоги и шаблоны файловых шаблонов. Это означает, что вы можете делать такие вещи, как:

Обратите внимание на обратную косую черту ( \ ) перед * . Это необходимо, потому что Git выполняет собственное расширение имени файла в дополнение к расширению имени файла вашей оболочки. Эта команда удаляет все файлы с расширением .log в каталоге log/. Или вы можете сделать что-то вроде этого:

Эта команда удаляет все файлы, имена которых заканчиваются на ~ .

Перемещение файлов

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

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

и это работает нормально. На самом деле, если вы запустите что-то подобное и посмотрите на статус, вы увидите, что Git считает это переименованным файлом:

Однако это эквивалентно запуску чего-то вроде этого:

Git неявно определяет, что это переименование, поэтому не имеет значения, переименовываете ли вы файл таким образом или с помощью команды mv. Единственная реальная разница в том, что git mv — это одна команда вместо трех — это функция удобства. Что еще более важно, вы можете использовать любой инструмент, который вам нравится, для переименования файла и обращения к add/rm позже, до фиксации.

Установка и настройка

Получение и создание проектов

Базовый снимок

Ветвление и слияние

Обмен проектами и их обновление

Осмотр и сравнение

Исправление

Отладка

Электронная почта

Внешние системы

Администратор сервера

Руководства

Администрирование

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

Проверьте свою версию git, запустив

git-rm - Удалить файлы из рабочего дерева и из индекса

ОБЗОР

ОПИСАНИЕ

Удалить файлы, соответствующие пути, из индекса или из рабочего дерева и индекса. git rm не удалит файл только из вашего рабочего каталога. (Нет возможности удалить файл только из рабочего дерева и при этом сохранить его в индексе; используйте /bin/rm, если вы хотите это сделать.) Удаляемые файлы должны быть идентичны вершине ветви, и никакие обновления их содержимого не могут быть размещены в индексе, хотя это поведение по умолчанию можно переопределить с помощью параметра -f. Если задан параметр --cached, подготовленное содержимое должно соответствовать либо концу ветки, либо файлу на диске, что позволяет удалить файл только из индекса. Когда используются разреженные проверки (см. git-sparse-checkout[1]), git rm удалит пути только в шаблонах разреженных проверок.

ВАРИАНТЫ

Файлы для удаления. Начальное имя каталога (например, dir для удаления dir/file1 и dir/file2 ) может быть задано для удаления всех файлов в каталоге и рекурсивно всех подкаталогов, но для этого требуется явный указанный параметр -r.

Команда удаляет только те пути, которые известны Git.

Подстановка файлов соответствует границам каталогов. Таким образом, при наличии двух каталогов d и d2 существует разница между использованием git rm 'd*' и git rm 'd/*' , так как первый также удалит весь каталог d2 .

Подробнее см. в записи pathspec в gitglossary[7].

Переопределить проверку актуальности.

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

Разрешить рекурсивное удаление, если задано начальное имя каталога.

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

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

Выйти с нулевым статусом, даже если не найдено ни одного файла.

Разрешить обновление записей индекса за пределами конуса разреженной проверки. Обычно git rm отказывается обновлять записи индекса, пути которых не соответствуют конусу разреженной проверки. См. git-sparse-checkout[1] для получения дополнительной информации.

git rm обычно выводит одну строку (в виде команды rm) для каждого удаленного файла. Этот параметр подавляет этот вывод.

Pathspec передается вместо аргументов командной строки. Если точно - то используется стандартный ввод. Элементы Pathspec разделяются символами LF или CR/LF. Элементы Pathspec можно заключать в кавычки, как описано для переменной конфигурации core.quotePath (см. git-config[1]). См. также --pathspec-file-nul и global --literal-pathspecs .

Имеет смысл только с параметром --pathspec-from-file . Элементы Pathspec разделяются символом NUL, а все остальные символы воспринимаются буквально (включая символы новой строки и кавычки).

УДАЛЕНИЕ ФАЙЛОВ, ИСЧЕЗНУВШИХ ИЗ ФАЙЛОВОЙ СИСТЕМЫ

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

Использование «git commit -a»

Если вы предполагаете, что ваша следующая фиксация должна записывать все изменения отслеживаемых файлов в рабочем дереве и записывать все удаления файлов, которые были удалены из рабочего дерева с помощью rm (в отличие от git rm ), используйте git commit -a , так как он автоматически заметит и запишет все удаления. Вы также можете получить аналогичный эффект без фиксации, используя git add -u .

Использование «git add -A»

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

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

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

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

Другие способы

Если все, что вы действительно хотите сделать, это удалить из индекса файлы, которых больше нет в рабочем дереве (возможно, из-за того, что ваше рабочее дерево грязное и вы не можете использовать git commit -a ), используйте следующую команду :

ПОДМОДУЛИ

Только подмодули, использующие git-файл (что означает, что они были клонированы с помощью Git версии 1.7.8 или новее), будут удалены из рабочего дерева, поскольку их репозиторий находится внутри каталога .git суперпроекта. Если подмодуль (или один из вложенных в него) по-прежнему использует каталог .git, git rm переместит каталог git подмодулей в каталог git суперпроектов, чтобы защитить историю подмодуля. Если он существует, то подмодуль. раздел в файле gitmodules[5] также будет удален, а этот файл будет помещен в промежуточное состояние (если только не используются --cached или -n).

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

Если вы хотите удалить только локальное извлечение подмодуля из вашего рабочего дерева без фиксации удаления, используйте вместо этого git-submodule[1] deinit. Также см. gitsubmodules[7] для получения подробной информации об удалении подмодуля.

ПРИМЕРЫ

Удаляет из индекса все файлы *.txt, находящиеся в каталоге Documentation и любых его подкаталогах.

Обратите внимание, что в этом примере звездочка * взята из оболочки; это позволяет Git, а не оболочке, расширять пути к файлам и подкаталогам в каталоге Documentation/.

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

У меня есть 2 варианта:

Удалите эти файлы из репозитория git. Добавьте их в .gitignore. Попросите всех членов моей команды добавить эти файлы обратно в их локальный проект с их собственными настройками.

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

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

6 ответов 6

Вот что вы хотите сделать:

Добавьте все файлы, по отдельности или в папке, которые вы хотите удалить из репозитория, но сохраните локально в .gitignore.
Выполните git rm --cached put/here/your/file.ext для каждого файла или git rm --cached folder/\*, если они находятся в папке. (Это /\*, потому что вам нужно экранировать *)
Зафиксируйте изменения.
Отправить на удаленный сервер.

После этого вы эффективно "игнорируете отслеживаемые файлы, не удаляя их", удаляя их из репозитория и оставляя их нетронутыми в вашей системе. Затем, когда ваша команда извлечет изменения, они извлекут файл .gitignore, и их отдельные файлы конфигурации не будут перезаписаны файлами в репозитории, потому что вы их проигнорировали и удалили из него. Кроме того, поскольку теперь новый .gitignore игнорирует эти файлы, у каждого будет своя их версия, не отображающаяся в «незафиксированных изменениях».

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

@ardila Это правда. Простое решение — создать скрипт, будь то npm, powershel или что-то еще, который можно запустить один раз для новых пользователей репозитория и сгенерировать файл gitignored. Или просто скажите им, как вручную настроить этот файл, игнорируемый git, если он не может быть сгенерирован.

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

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

Кажется, здесь найдено простое решение. Добавить файл/каталог только в .gitignore недостаточно, но git позволит вам вручную «игнорировать» изменения в файле/каталоге:

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

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

Технически ваше требование противоречиво.

На более философском уровне это (кажется) столкновение между открытым исходным кодом и корпоративной философией.

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

git либо отслеживает файл, либо игнорирует его.

Отслеживание очень простое. Просто ничего не делайте… кроме использования git! И любой файл отслеживается.
Игнорировать почти так же просто — просто убедитесь, что оно соответствует чему-то в вашем файле gitignore.
Но вы не можете делать и то, и другое!!
Главное предостережение. Перемещение файла из состояния отслеживаемого в состояние игнорируемого несколько нетривиально — простое добавление подходящего шаблона в gitignore не отключит его после отслеживания. соответствующие