Как удалить файл из индекса в git?

Как удалить файл из индекса (= staging area = cache), не удаляя его из файловой системы?


Вы хотите:

  git rm --cached [file]  

Если вы опустите параметр - cached , он будет также удалите его из рабочего дерева. git rm немного безопаснее, чем git reset , потому что вы будете предупреждены, если поэтапное содержимое не соответствует ни кончику ветки, ни файлу. на диске. (Если этого не произошло, вам нужно добавить - force .)


143

Это должно деактивировать для вас (без удаления или иного изменения файла):

  git reset  

Улучшите этот ответ
отредактировано 7 ноября ’19 в 02:11
ответил 8 февраля 2010 г., 17:00
  • 6
    Это удаляет последнее изменение для конкретного файла, но сохраняет его в репозитории (удаленном) после фиксации и нажатия. – Powder366, 30 июня ’16 в 18:25
  • 2
    Это тот ответ, который я искал. Обратите внимание, что указывать HEAD необязательно. – Майкл Дорст, 06 ноя., В 22:31
  • Хороший замечание @MichaelDorst. Я обновил ответ, чтобы опустить HEAD ! – Дэвид Андерхилл 7 нояб. ’19 в 2:11
добавить комментарий |

Это должно деактивировать для вас (без удаления или иного изменения файла):

   git reset  

4

  git reset HEAD   

для удаления определенного файла из индекса.

и

git reset HEAD

для удаления всех проиндексированных файлов.

Улучшить этот ответ
ответил 31 июля ’18 в 8:29
добавить комментарий |

  git reset HEAD   

для удаления определенного файл из индекса.

и

git reset HEAD

для удаления всех проиндексированных файлов.


2

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

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

  • git gui gitk
  • git cola

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


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

  • git rm --cached [file]
  • git reset HEAD

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


Работа без индекса

Основываясь на комментариях и голосах, я пришел к выводу, что многие люди используют индекс все время. Я не. Вот как:

  • Зафиксируйте всю мою рабочую копию (типичный случай): git commit -a
  • Зафиксируйте всего несколько файлов: git commit (список файлов)
  • Зафиксируйте все, кроме нескольких измененных файлов: git commit -a затем изменить с помощью git gui
  • Графически просмотрите все изменения в рабочей копии: git difftool - -dir-diff --tool = meld
Улучшите этот ответ
отредактировано 15 августа 2016 г. в 20:17
ответил 4 октября 2015 г. в 17:30
  • @Martin: Думаю, это зависит от вашего рабочего процесса. В моем подходе я никогда не использую индекс напрямую. Когда я хочу сохранить свою работу, я просто выполняю полные коммиты с помощью git commit -a . Когда я отвечал на этот вопрос, это было потому, что я сделал (экзотический) «обратный выбор вишни», который помещает файлы в индекс для вас, но я хотел отредактировать файл перед фиксацией. Я вынул файл из индекса, пока редактировал его, чтобы различия работали так, как я привык. – Брент Брэдберн, 4 октября 2015 г., 16:00
  • мой случай использования был очень узким и бесполезным: создать ветку; добавить папку с файлами только для ветки; переключиться на мастера; слияние; ops, добавлена ​​неправильная папка в master, добавьте ее в gitignore; файлы не будут удалены из коммита – конечно, лучшим решением было бы сразу использовать rm , но сначала я подумал, что переключение ветвей не убьет игнорируемые папка. но … Я использую инструмент github “на основе графического интерфейса”, который мне подходит и поддерживает некоторое управление индексами, но не поддерживает это. и что, я должен использовать 2 графических интерфейса для узкого использования? все еще не могу согласиться с ответом. – cregox, 23 фев. 2016, 20:41
  • 3
    Это явно непопулярный ответ. Однако я совершенно уверен, что предлагаемый мной подход подходит для некоторых людей (включая меня). Я использую один из этих инструментов для управления индексом несколько раз в год. – Брент Брэдберн, 20 апр. ’16 в 15:21
  • 1
    В настоящее время редакторы программирования и IDE, вероятно, будут поддерживать графические манипуляции с индексами. По крайней мере, это делает Atom на GitHub. – Брент Брэдберн, 10 декабря 2018 г., в 1:15
  • 1
    Я предпочитаю интерфейс cli над графическим интерфейсом в любое время, даже если это более опасно. Это позволит мне использовать git даже без графического интерфейса, что меня утешает (вместо того, чтобы теряться, например, когда я не могу установить такие инструменты на удаленном сервере). Все сказанное в этом ответе совершенно верно и не заслуживает отрицательных голосов “кли-элитистов”, +1 за предоставление хорошей альтернативы графическому интерфейсу! – SidOfc 2 мая ’20 в 10:22
| показать 6 дополнительных комментариев

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

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

  • git gui gitk
  • git cola

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


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

  • git rm --cached [file]
  • git reset HEAD

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


Работа без индекса

Основываясь на комментариях и голосах, я пришел к выводу, что многие люди используют индекс все время. Я не. Вот как:

  • Зафиксируйте всю мою рабочую копию (типичный случай): git commit -a
  • Зафиксируйте всего несколько файлов: git commit (список файлов)
  • Зафиксируйте все, кроме нескольких измененных файлов: git commit -a затем изменить с помощью git gui
  • Графически просмотрите все изменения в рабочей копии: git difftool - -dir-diff --tool = meld

1

Используйте git rm --cached [file] только для удаления файла из индекса.

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

   % git add First.txt% git ls-filesFirst.txt% git commit -m "Первый"% git ls-files First.txt% git reset First.txt% git ls-files First.txt  

ПРИМЕЧАНИЕ. git reset First.txt не влияет на индекс после фиксации.

Это подводит меня к теме git restore --staged код>. Его можно использовать (предположительно после первой фиксации) для удаления добавленных файлов из индекса, если файлы никогда не фиксировались .

 % git  добавить Second.txt% git status В ветке master Изменения, которые необходимо зафиксировать: (используйте "git restore --staged  ..." для отмены постановки) новый файл: Second.txt% git ls-files First.txtSecond.txt% git  restore --staged Second.txt% git ls-files First.txt% git add Second.txt% git commit -m "Second"% git status На ветке master ничего не фиксировать, рабочее дерево clean% git ls-files First.txt Second  .txtDesktop/Test% git restore --staged .Desktop/Test% git ls-filesFirst.txt Second.txtDesktop/Test% git reset.  Рабочий стол/Тест% git ls-filesFirst.txtSecond.txt% git rm --cached -r .rm 'First.txt'rm' Second.txt '% git ls-files  

tl; dr Посмотрите на последние 15 строк. Если вы не хотите, чтобы вас путали с первой фиксацией, второй фиксацией, перед фиксацией, после фиксации …. всегда используйте git rm --cached [file]

Улучшите этот ответ
отредактировано 12 июля ’20 в 14:02
ответил 12 июля ’20 в 12:47
добавить комментарий |

Используйте git rm --cached [file] только для удаления файла из индекса.

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

 % git add First.txt% git ls-filesFirst.txt% git commit -m "Первый"% git ls-files First.txt% git reset First.txt% git ls  -files First.txt  

ПРИМЕЧАНИЕ. git reset First.txt не влияет на индекс после commit.

Это подводит меня к теме git restore --staged . Его можно использовать (предположительно после первой фиксации) для удаления добавленных файлов из индекса, если файлы никогда не фиксировались .

 % git  добавить Second.txt% git status В ветке master Изменения, которые необходимо зафиксировать: (используйте "git restore --staged  ..." для отмены постановки) новый файл: Second.txt% git ls-files First.txtSecond.txt% git  restore --staged Second.txt% git ls-files First.txt% git add Second.txt% git commit -m "Second"% git status На ветке master ничего не фиксировать, рабочее дерево clean% git ls-files First.txt Second  .txtDesktop/Test% git restore --staged .Desktop/Test% git ls-filesFirst.txt Second.txtDesktop/Test% git reset.  Рабочий стол/Тест% git ls-filesFirst.txtSecond.txt% git rm --cached -r .rm 'First.txt'rm' Second.txt '% git ls-files  

tl; dr Посмотрите на последние 15 строк. Если вы не хотите, чтобы вас путали с первой фиксацией, второй фиксацией, перед фиксацией, после фиксации …. всегда используйте git rm --cached [file]


1

Согласно моему скромному мнению и моему опыту работы с git, постановка Площадь не совпадает с индексом. Я могу, конечно, ошибаться, но, как я уже сказал, мой опыт использования git и моя логика говорят мне, что этот индекс – это структура, которая следует за вашими изменениями в вашей рабочей области (локальном репозитории), которые не исключаются путем игнорирования настроек и промежуточной области – хранить файлы, фиксацию которых уже подтверждены, например файлы в индексе, для которых была запущена команда добавления.. Вы не замечаете и не понимаете эту «небольшую» разницу, потому что вы используете git commit -a -m "comment" , добавляя индексированные и кэшированные файлы в рабочую область и выполняя фиксацию одной командой или используя IDE. как IDEA для этого слишком часто. И кеш – это то, что сохраняет изменения в индексированных файлах. Если вы хотите удалить файл из индекса, который не был добавлен в промежуточную область ранее, варианты, предложенные перед вами, подходят для вас, но … Если вы уже сделали это, вам понадобится использовать

  Git restore --staged  

И, пожалуйста, не спрашивайте меня, где я был 10 лет назад … Я скучал по тебе, этот ответ для будущих поколений)

Улучшите этот ответ
отредактировано 22 сентября ’20 в 9:14
ответил 22 сен ’20 в 9:03
добавить комментарий |

Согласно моему скромному мнению и моему опыту работы с git, промежуточная область – это не то же самое, что index. Я могу, конечно, ошибаться, но, как я уже сказал, мой опыт использования git и моя логика говорят мне, что этот индекс – это структура, которая следует за вашими изменениями в вашей рабочей области (локальном репозитории), которые не исключаются путем игнорирования настроек и промежуточной области – хранить файлы, фиксацию которых уже подтверждены, то есть файлы в индексе, для которого была запущена команда добавления. Вы не замечаете и не понимаете эту «небольшую» разницу, потому что вы используете git commit -a -m "comment" , добавляя индексированные и кэшированные файлы в рабочую область и выполняя фиксацию одной командой или используя IDE. как IDEA для этого слишком часто. И кеш – это то, что сохраняет изменения в индексированных файлах. Если вы хотите удалить файл из индекса, который не был добавлен в промежуточную область ранее, варианты, предложенные перед вами, подходят для вас, но … Если вы уже сделали это, вам понадобится использовать

  Git restore --staged  

И, пожалуйста, не спрашивайте меня, где я был 10 лет назад … Я скучал по тебе, этот ответ для будущих поколений)



Как удалить файл из индекса git

Как удалить файл из index репозитория git, не удаляя файл из рабочего дерева?

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


Вы можете просто использовать git rm --cached notes.txt . Это сохранит файл, но удалит его из индекса.


3

git reset HEAD для удаления определенного файла.

и git reset HEAD для удаления всех файлов из индекса git.

Улучшить этот ответ
отредактировал 31 июля ’18 в 9:41
Джефф Шаллер ♦
57.6k1212 золотых знаков8888 серебряных знаков200200 бронзовых знаков
ответ дан 31 июля ’18 в 11: 27
  • Этот ответ появился через 8 лет после решения Герта, ха С тех пор изменилась семантика команды git reset ? – Камил 26 апр. ’19 в 6:36
добавить комментарий |

git reset HEAD для удаления определенного файла.

и git reset HEAD для удаления всех файлов из индекса git.

Оцените статью
futurei.ru
Добавить комментарий