Как удалить файлы из Git
Очень важно, чтобы сообщение о фиксации соответствовало изменениям. Что, если вы случайно разместили файл, который не предназначался для текущей фиксации?
git rm --cached
Указание имени файла при использовании приведенной выше команды приведет к удалению одного файла (или нескольких, в зависимости от того, сколько файлов вы указали).
Если вы хотите узнать больше, продолжайте читать.
Команда Git rm
Команда git rm используется для удаления файлов из рабочего дерева, а также из индекса.
Эта команда имеет удобный флаг —cached . При использовании этого флага вместе с указанием имени одного или нескольких файлов они удаляются из индекса.
Это означает, что файлы рабочего дерева не будут затронуты. Только то, что они будут удалены из промежуточной области, которую использует Git.
Давайте посмотрим на пример
$ git status On branch master No commits yet Changes to be committed: (use "git rm --cached . " to unstage) new file: README.md $ git rm --cached README.md rm 'README.md' $ git status On branch master No commits yet Untracked files: (use "git add . " to include in what will be committed) README.md
Я добавил файл README.md в промежуточную область и через некоторое время понял, что это ошибка. Итак, чтобы удалить «README.md» из промежуточной области, я использовал команду git rm и удалил его.
После удаления его из промежуточной области я запускаю git status и вижу, что README.md не отслеживается, а также что он не был удален (что было бы очень катастрофично).
Команда git rm вместе с флагом —cached является полной противоположностью команде git add и может использоваться безопасно.
Команда сброса Git
Команда git reset сбросит текущий HEAD в состояние, указанное пользователем.
Сама по себе команда в этом контексте бесполезна, но мы можем использовать опцию двойного дефиса — , которая больше не будет интерпретировать аргументы как параметры. И наконец, укажите имя файла, который нужно удалить из промежуточной области.
Давайте посмотрим на пример, чтобы лучше понять это.
$ git status On branch master No commits yet Changes to be committed: (use "git rm --cached . " to unstage) new file: README.md $ git reset -- README.md $ git status On branch master No commits yet Untracked files: (use "git add . " to include in what will be committed) README.md
Как видите, файл README.md, который ранее находился в промежуточной области, теперь не размещен.
Заключение
Для удаления файла из локального репозитория Git в основном используются две команды. Это git rm и git reset , оба используются со специальными флагами для выполнения действия по удалению файлов.
Изменение файлов в Git (как удалить и переименовать файлы в git)
Мы уже знаем, как добавить файлы в промежуточную область git через Git bash, как записать содержимое в файл в этих файлах, как зафиксировать файл.
Этих операций достаточно для основы, но по мере того, как мы прогрессируем, наши ненужные файлы увеличиваются в хранилище. Кроме того, до сих пор не было возможности переименовать файл. После того как вы создали файл в Git, его имя оставалось неизменным на протяжении всего проекта. Сосредоточившись на том же вопросе, мы изучим некоторые операции в Git, которые охватывают изменения файлов в Git и научимся:
- Удалять файлы из репозитория Git.
- Переименовывать файлы в репозитории Git.
Как удалить файл с помощью Git в репозитории Git
Прежде чем начать что-то новое в Git, мы должны проверить состояние нашего репозитория. Это должен быть чистый репозиторий (никаких изменений, ожидающих фиксации в промежуточной области).
Начав работу, проверьте состояние репозитория, набрав git status:

Теперь, чтобы удалить файл, нужно создать файл. Создайте новый файл toolsqa.txt
touch toolsqa.txt

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

1 — Добавление изменений в промежуточную область.
2 — Проверка состояния репозитория Git.
3 — Фиксация изменений в репозитории Git.
Итак, теперь мы добавили этот файл в репозиторий Git. Давайте теперь удалим этот файл, набрав следующую команду и нажав клавишу enter:
git rm

Как только вы нажмете клавишу enter, ваш файл будет удален и появится сообщение rm .

Теперь давайте проверим состояние git и сообщение, которое он выдаст.

Переименование файлов в репозитории Git
Переименование файлов также является одной из наиболее часто используемых операций над файлом. Переименование может быть сделано из-за многих факторов. Как разработчик, возможно, вы хотите переименовать файл, созданный вашим коллегой-разработчиком. Какова бы ни была причина, вы будете часто сталкиваться с переименованием. Будучи важной частью Git, мы должны научиться переименовывать файл в репозитории Git.
Как переименовать файл с помощью Git
Поскольку у нас нет никакого файла в репозитории Git, создайте новый файл, например toolsqa.txt. После этого вы должны проверить состояние git. Подтвердите, что это чистый каталог, как мы уже делали выше. Как только все будет сделано, введите следующую команду и нажмите клавишу enter:

Проверьте состояние репозитория через git status.

Git обнаружил, что файл был переименован. Запомните этот шаг, так как он будет играть важную роль, когда мы будем переименовывать файл вне git. Зафиксируйте эти изменения.
Как переименовать файл вне Git
В этом разделе мы рассмотрим, как Git реагирует, когда файл переименовывается, не сообщая об этом Git. Используйте ту же команду без “git”.
Введите следующую команду в Git Bash и нажмите клавишу enter:

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

Здесь очень важно заметить реакцию Git. Git удалил файл под названием renaming.txt и добавил новый файл toolsqa.txt. Оба они в настоящее время не присутствуют в плацдарме. Это совсем не то, что мы видели выше. Там Git упомянул, что файл был переименован. Теперь нам нужно добавить эти изменения в промежуточную зону.

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

Выделенная строка гласит: rename renaming.txt -> toolsqa.txt (100%)
Означает, что предыдущий файл и новый файл абсолютно одинаковы и нет никакой разницы. Это называется уровнем доверия. Если бы вы внесли какие-либо изменения в новый файл, а затем зафиксировали эти изменения, он показал бы менее 100%.

В последнем уроке мы познакомились с командой Git fetch и Read more

В одной из последних статей мы узнали о команде Git Read more
Мы уже знаем, как вносить изменения в локальное хранилище и Read more

Команда git push при выполнении перемещает изменения, внесенные пользователем на Read more

«Клонирование» означает создание идентичных особей естественным или искусственным путем. Клонирование Read more

Сегодня мы узнаем, как скопировать чужой репозиторий в наш аккаунт Read more
Раздел: Git Метки: Git
Изменение файлов в Git (как удалить и переименовать файлы в git) : 2 комментария
- Elisey 13.10.2021 Спасибо, помогло!)
- wpmaster Автор записи 21.10.2021 Рада помочь)
git rm и git mv — удаление и переименование в Git
Еще один важный практический вопрос при работе с Git — это операции с файлами.
В частности, это операции удаления и переименования файлов. В системе Git имеются специальные команды, которые очень похожи на консольные команды
в Linux/Mac OS. Но для Git они выглядят несколько иначе:
git rm
— для удаления файлов и
git mv
— для переименования файлов. Ниже я рассмотрю обе эти комадны более подробно.
Команда git rm
Для удаления файлов в системе Git, как уже упоминалось выше, имеется специальная команда
git rm
. Ее отличие от обычной консольной команды
(в том же Linux) заключается в особенности самой системы Git.
Как хорошо известно, в системе Git файл может одновременно существовать в трех ипостасях: в области “Working Directory”, в области “Staging Area”, в области “Repository”. Удаление файла из области “Working Directory” не приведет к его удалению из областей “Staging Area” и “Repository”.
Поэтому, чтобы удалить файл, нужно (в идеале) выполнить три команды подряд для удаления файла из Рабочей области “Working Directory”, затем из области индекса “Staging Area” и потом из области репозитория “Repository”:

index.html
с помощью команды
git mv

Вот и все несложные операции по перемещению\переименованию или удалению файлов с помощью команд
7.3 Инструменты Git — Припрятывание и очистка
Часто пока вы работаете над одной частью вашего проекта и всё находится в беспорядке, у вас возникает желание сменить ветку и поработать над чем-то ещё. Сложность при этом заключается в том, что вы не хотите фиксировать наполовину сделанную работу только для того, чтобы иметь возможность вернуться к ней позже. Справиться с ней помогает команда git stash .
Операция stash берет изменённое состояние вашего рабочего каталога, то есть изменённые отслеживаемые файлы и проиндексированные изменения, и сохраняет их в хранилище незавершённых изменений, которые вы можете в любое время применить обратно.
Примечание
Переход на git stash push
В конце октября 2017 года в списке рассылки Git проходило обширное обсуждение, по итогам которого команда git stash save признана устаревшей в пользу существующей альтернативы git stash push . Основная причина этого заключается в том, что в git stash push есть возможность сохранить выбранные спецификации пути, что не поддерживает git stash save .
Команда git stash save не исчезнет в ближайшее время, поэтому не беспокойтесь о её внезапной пропаже. Но вы можете начать переход на push для использования новой функциональности.
Припрятывание ваших наработок
Для примера, предположим, что вы перешли в свой проект, начали работать над несколькими файлами и, возможно, добавили в индекс изменения одного из них. Если вы выполните git status , то увидите ваше изменённое состояние:
$ git status Changes to be committed: (use "git reset HEAD . " to unstage) modified: index.html Changes not staged for commit: (use "git add . " to update what will be committed) (use "git checkout -- . " to discard changes in working directory) modified: lib/simplegit.rb
Теперь вы хотите сменить ветку, но пока не хотите фиксировать ваши текущие наработки; поэтому вы припрячете эти изменения. Для того, чтобы припрятать изменение в выделенное для этого специальное хранилище, выполните git stash или git stash push :
$ git stash Saved working directory and index state \ "WIP on master: 049d078 Create index file" HEAD is now at 049d078 Create index file (To restore them type "git stash apply")
Теперь вы можете увидеть, что рабочая копия не содержит изменений:
$ git status # On branch master nothing to commit, working directory clean
В данный момент вы можете легко переключать ветки и работать в любой; ваши изменения сохранены. Чтобы посмотреть список припрятанных изменений, вы можете использовать git stash list :
$ git stash list stash@: WIP on master: 049d078 Create index file stash@: WIP on master: c264051 Revert "Add file_size" stash@: WIP on master: 21d80a5 Add number to log
В данном примере, предварительно были припрятаны два изменения, поэтому теперь вам доступны три различных отложенных наработки. Вы можете применить только что припрятанные изменения, используя команду, указанную в выводе исходной команды: git stash apply . Если вы хотите применить одно из предыдущих припрятанных изменений, вы можете сделать это, используя его имя, вот так: git stash apply stash@ . Если вы не укажете имя, то Git попытается восстановить самое последнее припрятанное изменение:
$ git stash apply On branch master Changes not staged for commit: (use "git add . " to update what will be committed) (use "git checkout -- . " to discard changes in working directory) modified: index.html modified: lib/simplegit.rb no changes added to commit (use "git add" and/or "git commit -a")
Как видите, Git восстановил в файлах изменения, которые вы отменили ранее, когда прятали свои наработки. В данном случае при применении отложенных наработок ваш рабочий каталог был без изменений, а вы пытались применить их в той же ветке, в которой вы их и сохранили; но отсутствие изменений в рабочем каталоге и применение их в той же ветке не являются необходимыми условиями для успешного восстановления припрятанных наработок. Вы можете припрятать изменения, находясь в одной ветке, а затем переключиться на другую и попробовать восстановить эти изменения. Также при восстановлении припрятанных наработок в вашем рабочем каталоге могут присутствовать изменённые и незафиксированные файлы — Git выдаст конфликты слияния, если не сможет восстановить какие-то наработки.
Спрятанные изменения будут применены к вашим файлам, но файлы, которые вы ранее добавляли в индекс, не будут добавлены туда снова. Для того, чтобы это было сделано, вы должны запустить git stash apply с опцией —index , при которой команда попытается восстановить изменения в индексе. Если вы выполните команду таким образом, то полностью восстановите ваше исходное состояние:
$ git stash apply --index On branch master Changes to be committed: (use "git reset HEAD . " to unstage) modified: index.html Changes not staged for commit: (use "git add . " to update what will be committed) (use "git checkout -- . " to discard changes in working directory) modified: lib/simplegit.rb
Команда apply только пытается восстановить припрятанные наработки — при этом они останутся в хранилище. Для того, чтобы удалить их, вы можете выполнить git stash drop , указав имя удаляемых изменений:
$ git stash list stash@: WIP on master: 049d078 Create index file stash@: WIP on master: c264051 Revert "Add file_size" stash@: WIP on master: 21d80a5 Add number to log $ git stash drop stash@ Dropped stash@ (364e91f3f268f0900bc3ee613f9f733e82aaed43)
Вы также можете выполнить git stash pop , чтобы применить припрятанные изменения и тут же удалить их из хранилища.
Необычное припрятывание
У припрятанных изменений есть несколько дополнительных вариантов использования, которые также могут быть полезны. Первый — это использование довольно популярной опции —keep-index с командой git stash . Она просит Git не только припрятать то, что вы уже добавили в индекс, но одновременно оставить это в индексе.
$ git status -s M index.html M lib/simplegit.rb $ git stash --keep-index Saved working directory and index state WIP on master: 1b65b17 added the index file HEAD is now at 1b65b17 added the index file $ git status -s M index.html
Другой распространённый вариант, который вы, возможно, захотите использовать — это припрятать помимо отслеживаемых файлов также и неотслеживаемые. По умолчанию git stash будет сохранять только изменённые и проиндексированные отслеживаемые файлы. Если вы укажете опцию —include-untracked или -u , Git также припрячет все неотслеживаемые файлы, которые вы создали. Однако включение этой опции по-прежнему не будет прятать файлы с явным игнорированием; чтобы дополнительно припрятать игнорируемые файлы, используйте —all (или просто -a ).
$ git status -s M index.html M lib/simplegit.rb ?? new-file.txt $ git stash -u Saved working directory and index state WIP on master: 1b65b17 added the index file HEAD is now at 1b65b17 added the index file $ git status -s $
И наконец, если вы укажете флаг —patch , Git не будет ничего прятать, а вместо этого в интерактивном режиме спросит вас о том, какие из изменений вы хотите припрятать, а какие оставить в вашем рабочем каталоге.
$ git stash --patch diff --git a/lib/simplegit.rb b/lib/simplegit.rb index 66d332e..8bb5674 100644 --- a/lib/simplegit.rb +++ b/lib/simplegit.rb @@ -16,6 +16,10 @@ class SimpleGit return `# 2>&1`.chomp end end + + def show(treeish = 'master') + command("git show #") + end end test Stash this hunk [y,n,q,a,d,/,e,?]? y Saved working directory and index state WIP on master: 1b65b17 added the index file
Создание ветки из припрятанных изменений
Если вы спрятали некоторые изменения, оставили их на время, а сами продолжили работать в той же ветке, у вас могут возникнуть проблемы с восстановлением наработок. Если восстановление будет затрагивать файл, который уже был изменён с момента сохранения наработок, то вы получите конфликт слияния и должны будете попытаться разрешить его. Если вам нужен более простой способ снова протестировать припрятанные изменения, вы можете выполнить команду git stash branch , которая создаст для вас новую ветку, перейдёт на коммит, на котором вы были, когда прятали свои наработки, применит на нём эти наработки и затем, если они применились успешно, удалит эти припрятанные изменения:
$ git stash branch testchanges M index.html M lib/simplegit.rb Switched to a new branch 'testchanges' On branch testchanges Changes to be committed: (use "git reset HEAD . " to unstage) modified: index.html Changes not staged for commit: (use "git add . " to update what will be committed) (use "git checkout -- . " to discard changes in working directory) modified: lib/simplegit.rb Dropped refs/stash@ (29d385a81d163dfd45a452a2ce816487a6b8b014)
Это удобное сокращение для того, чтобы легко восстановить припрятанные изменения и поработать над ними в новой ветке.
Очистка рабочего каталога
Наконец, у вас может возникнуть желание не прятать некоторые из изменений или файлов в вашем рабочем каталоге, а просто избавиться от них. Команда git clean сделает это для вас.
Одной из распространённых причин для этого может быть удаление мусора, который был сгенерирован при слиянии или внешними утилитами, или удаление артефактов сборки в процессе её очистки.
Вам нужно быть очень аккуратными с этой командой, так как она предназначена для удаления неотслеживаемых файлов из вашего рабочего каталога. Даже если вы передумаете, очень часто нельзя восстановить содержимое таких файлов. Более безопасным вариантом является использование команды git stash —all для удаления всего, но с сохранением этого в виде припрятанных изменений.
Предположим, вы хотите удалить мусор и очистить ваш рабочий каталог; вы можете сделать это с помощью git clean . Для удаления всех неотслеживаемых файлов в вашем рабочем каталоге, вы можете выполнить команду git clean -f -d , которая удалит все файлы и также все каталоги, которые в результате станут пустыми. Параметр -f (сокращение от слова force — заставить) означает принудительное удаление, подчеркивая, что вы действительно хотите это сделать, и требуется, если переменная конфигурации Git clean.requireForce явным образом не установлена в false .
Если вы хотите только посмотреть, что будет сделано, вы можете запустить команду с опцией -n , которая означает «имитируй работу команды и скажи мне, что ты будешь удалять».
$ git clean -d -n Would remove test.o Would remove tmp/
По умолчанию команда git clean будет удалять только неотслеживаемые файлы, которые не добавлены в список игнорируемых. Любой файл, который соответствует шаблону в вашем .gitignore , или другие игнорируемые файлы не будут удалены. Если вы хотите удалить и эти файлы (например, удалить все .o -файлы, генерируемые в процессе сборки, и таким образом полностью очистить сборку), вы можете передать команде очистки опцию -x .
$ git status -s M lib/simplegit.rb ?? build.TMP ?? tmp/ $ git clean -n -d Would remove build.TMP Would remove tmp/ $ git clean -n -d -x Would remove build.TMP Would remove test.o Would remove tmp/
Если вы не знаете, что сделает при запуске команда git clean , всегда сначала выполняйте её с опцией -n , чтобы проверить дважды, перед заменой -n на -f и выполнением настоящей очистки. Другой способ, который позволяет вам более тщательно контролировать сам процесс — это выполнение команды с опцией -i (в «интерактивном» режиме).
Ниже выполнена команда очистки в интерактивном режиме.
$ git clean -x -i Would remove the following items: build.TMP test.o *** Commands *** 1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit 6: help What now>
Таким образом, вы можете просмотреть каждый файл индивидуально или указать шаблоны для удаления в интерактивном режиме.
Примечание
Существует причудливая ситуация, когда вам, возможно, придется проявить особую настойчивость, попросив Git очистить ваш рабочий каталог. Если вы оказались в рабочем каталоге, в который вы скопировали или клонировали другие репозитории Git (возможно, в виде подмодулей), даже git clean -fd откажется удалить эти каталоги. В таких случаях вам нужно добавить второй параметр -f для акцентирования.