Я по ошибке добавил файлы в Git с помощью команды:
git add myfile.txt
Я еще не запускал git commit
. Есть ли способ отменить это, чтобы эти файлы не были включены в коммит?
Я по ошибке добавил файлы в Git с помощью команды:
git add myfile.txt
Я еще не запускал git commit
. Есть ли способ отменить это, чтобы эти файлы не были включены в коммит?
Вы можете отменить git add
перед фиксацией с помощью
git reset <file>
который удалит его из текущего индекса (список, который будет зафиксирован), ничего не меняя.
Вы можете использовать
git reset
без имени файла, чтобы отключить все необходимые изменения. Это может пригодиться, когда файлов слишком много, чтобы их можно было перечислить один за другим за разумный промежуток времени.
В старых версиях Git приведенные выше команды эквивалентны git reset HEAD <file>
и git reset HEAD
соответственно и завершатся ошибкой, если HEAD
не определено (потому что вы еще не сделали никаких коммитов в своем репозитории) или неоднозначны (потому что вы создали ветку с именем HEAD
, которая это глупая вещь, которую вы не должны делать). Этот был изменен в Git 1.8. 2, поэтому в современных версиях Git вы можете использовать приведенные выше команды еще до совершения первого коммита:
git reset (без параметров или параметров) используется для вывода ошибки, когда в вашей истории нет никаких коммитов, но теперь он дает вам пустой индекс (для соответствия несуществующей фиксации, которую вы даже не используете).
Документация: git reset
git add
перезаписала предыдущую поэтапную незавершенную версию, мы не сможем ее восстановить. Я попытался уточнить это в своем ответе ниже.
- person leonbloy; 06.05.2013
git reset HEAD *.ext
, где ext
- это файлы с заданным расширением, которые вы хотите отменить. Для меня это было *.bmp
& *.zip
- person boulder_ruby; 26.11.2013
git rm --cached
), это означает, что вы готовитесь совершить фиксацию, которая удаляет этот файл. git reset HEAD <filename>
, с другой стороны, скопирует файл из HEAD в индекс, так что следующая фиксация не покажет никаких изменений, внесенных в этот файл.
- person Wildcard; 16.03.2016
git reset -p
точно так же, как git add -p
. Это круто!
- person donquixote; 18.07.2016
-p
определенно великолепен, и он используется во многих командах git (а не только в сбросе и добавлении). Но чтобы ответить на @ WeDoTDD.com и @Johnny, git reset
сам по себе просто выясняет, знает ли Git об изменениях; он не очищает сами изменения. Для этого вам нужно сделать git checkout someFile.txt
(для отдельных файлов) или git reset --hard
(чтобы стереть все начисто). Однако ни одна из этих команд не вернется назад, поэтому будьте очень осторожны при их использовании.
- person machineghost; 15.12.2016
git add
, которое вы хотите восстановить (61/3AF3...
- ›идентификатор объекта 613AF3...
), затем git cat-file -p <object-id>
(возможно, стоит восстановить несколько часов работы, но также урок, который нужно делать чаще ...)
- person Peter Schneider; 31.07.2017
git add
- через git fsck --unreachable
, который перечислит все недостижимые объекты, которые вы затем можете проверить с помощью git show SHA-1_ID
или git fsck --lost-found
, которые будут ›записывать оборванные объекты в .git/lost-found/commit/
или .git/lost-found/other/
, в зависимости от типа. См. Также git fsck --help
- person iolsmit; 27.04.2018
"git restore --staged <file>..." to unstage
. См. stackoverflow.com/a/16044987/40422
- person Bill Hoag; 20.11.2019
git reset */commonlib/styles/*.scss
, чтобы найти все такие файлы, и это сработало.
- person akgupta; 22.01.2020
git reset <file>
, похоже, также удалил файл из моей файловой системы, что, очевидно, не то, что вам нужно.
- person crobar; 14.10.2020
Ты хочешь:
git rm --cached <added_file_to_undo>
Рассуждение:
Когда я был новичком в этом, я сначала попробовал
git reset .
(чтобы отменить все мое первоначальное добавление), только чтобы получить это (не очень) полезное сообщение:
fatal: Failed to resolve 'HEAD' as a valid ref.
Оказывается, это потому, что ссылка HEAD (ветка?) Не существует до момента первого коммита. То есть вы столкнетесь с той же проблемой новичка, что и я, если бы ваш рабочий процесс, как и мой, был примерно таким:
git init
git add .
git status
... много свитков дерьма от ...
=> Блин, я не хотел все это добавлять.
google "отменить git add"
=> найти переполнение стека - ура
git reset .
=> фатальный: не удалось разрешить "HEAD" как действительную ссылку.
Далее выясняется, что существует ошибка, зарегистрированная в отношении бесполезности это в списке рассылки.
И что правильное решение было прямо там, в выводе статуса Git (что, да, я замалчивал как `` дерьмо)
... # Changes to be committed: # (use "git rm --cached <file>..." to unstage) ...
И решение действительно - использовать git rm --cached FILE
.
Обратите внимание на предупреждения в другом месте: git rm
удаляет локальную рабочую копию файла, но не, если вы используете --cached. Вот результат git help rm
:
--cached Используйте эту опцию, чтобы деактивировать и удалить пути только из индекса. Файлы рабочего дерева, измененные или нет, останутся.
Я продолжаю использовать
git rm --cached .
удалить все и начать заново. Однако это не сработало, потому что, хотя add .
рекурсивно, оказывается, rm
требуется -r
для рекурсии. Вздох.
git rm -r --cached .
Хорошо, теперь я вернулся к тому, с чего начал. В следующий раз я собираюсь использовать -n
для пробного прогона и посмотреть, что будет добавлено:
git add -n .
Я заархивировал все в безопасное место, прежде чем поверить git help rm
в том, что --cached
ничего не разрушает (и что, если я ошибся в написании).
rm -rf .git
, git init
, потому что не доверял git rm --cached
сохранить мою рабочую копию. Это немного говорит о том, что git в некоторых местах все еще слишком сложен. git unstage
должна быть стандартной стандартной командой, мне все равно, могу ли я добавить ее в качестве псевдонима.
- person Adrian Macneil; 29.03.2011
git rm -r --cached .
отлично работает
- person Tom Davies; 22.11.2011
git reset
, попробуйте git reset *
вместо git reset .
- он отменяет этапы всех ранее размещенных вами файлов.
- person Marius Butuc; 10.12.2011
git add -p
- person jlundqvist; 29.04.2012
git reset HEAD <File>...
- person drahnr; 12.09.2012
git stash/git stash pop
, чтобы избежать архивирования / резервного копирования всего
- person chachan; 03.11.2012
git add
добавила новые файлы, но не изменений в существующих файлах .
- person naught101; 10.04.2013
.git
и повторная инициализация. Для случаев в хорошо используемом репо, где вы просто случайно добавили один файл, git rm --cached <file>
кажется лучшим, хотя после фиксации я получаю пугающий delete mode 100644 file
.
- person deed02392; 15.07.2013
git status
выводом git версии 1.8.1.4 правильный способ деактивации новых файлов: git reset HEAD <file>...
- person akostadinov; 28.08.2013
git reset
отменить все добавленные файлы, либо git reset <file>
, чтобы отменить определенный добавленный файл. git rm --cached
может работать на поверхности, но что на самом деле происходит, так это то, что он также удаляет его из истории отслеживания, что не является тем, что вы хотели бы делать, если только вы не добавили этот файл в файл gitignore, где этот файл не должен был отслеживаться в первое место, тогда в таком случае все было бы нормально.
- person JoeMoe1984; 03.06.2014
git rm --cached
- person JoeMoe1984; 03.06.2014
git rm --cache <filename>
, если файлы уже в индексе, но вы не хотите, чтобы они были в этой фиксации, используйте git reset <filename>
- person Ding-Yi Chen; 20.10.2016
Если вы наберете:
git status
Git расскажет, что ставится, и т. Д., Включая инструкции по отключению:
use "git reset HEAD <file>..." to unstage
Я считаю, что Git неплохо подталкивает меня к правильным поступкам в подобных ситуациях.
Примечание. В последних версиях Git (1.8.4.x) это сообщение было изменено:
(use "git rm --cached <file>..." to unstage)
add
ed (add
только сохранил новую версию в кеше - здесь будет отображаться ваше сообщение). В другом месте, если файл ранее не создавался, будет отображаться use "git rm --cached <file>..." to unstage
- person leonbloy; 06.05.2013
git reset HEAD <file>
- единственный, который будет работать, если вы хотите отключить удаление файла.
- person skerit; 24.02.2018
git reset HEAD
о отключении.
- person SilverWolf; 23.04.2018
git restore --staged <file>
. См. мой ответ ниже для получения обновлений.
- person prosoitos; 19.11.2020
Для пояснения: git add
перемещает изменения из текущего рабочего каталога в промежуточную область (индекс).
Этот процесс называется постановкой. Итак, наиболее естественная команда для обработки изменений (измененных файлов) очевидна:
git stage
git add
- это просто псевдоним для git stage
, который проще ввести
Жалко, что нет ни git unstage
, ни git unadd
команд. Соответствующий труднее угадать или запомнить, но он довольно очевиден:
git reset HEAD --
Мы можем легко создать для этого псевдоним:
git config --global alias.unadd 'reset HEAD --'
git config --global alias.unstage 'reset HEAD --'
И наконец, у нас есть новые команды:
git add file1
git stage file2
git unadd file2
git unstage file1
Лично я использую еще более короткие псевдонимы:
git a # For staging
git u # For unstaging
git stage
- это псевдоним для git add
, исторической команды как для Git, так и для других SCM. Он был добавлен в декабре 2008 года с коммитом 11920d28da в репозиторий Git git, если можно так сказать.
- person Obsidian; 12.09.2018
В дополнение к принятому ответу, если ваш ошибочно добавленный файл был огромным, вы, вероятно, заметите, что даже после удаления его из индекса с помощью 'git reset
' он все еще занимает место в каталоге .git
.
Не о чем беспокоиться; файл действительно все еще находится в репозитории, но только как «свободный объект». Он не будет скопирован в другие репозитории (через clone, push), а пространство в конечном итоге будет освобождено - хотя, возможно, не очень скоро. Если вы беспокоитесь, можете бегать:
git gc --prune=now
Обновление (далее я пытаюсь устранить некоторую путаницу, которая может возникнуть из-за ответов, получивших наибольшее количество голосов):
Итак, что же на самом деле отменить действия git add
?
git reset HEAD <file>
?
or
git rm --cached <file>
?
Строго говоря, и если не ошибаюсь: нет.
git add
нельзя отменить - в целом безопасно.
Давайте сначала вспомним, что на самом деле делает git add <file>
:
Если <file>
ранее не отслеживался, git add
добавляет его в кеш с текущим содержимым.
Если <file>
был уже отслежен, git add
сохраняет текущее содержание (снимок, версию) в кеш. В Git это действие по-прежнему называется добавить (а не просто обновить его), потому что две разные версии (снимки) файла рассматриваются как два разных элемента: следовательно, мы действительно добавляем новый элемент в кеш, который в конечном итоге будет зафиксирован позже.
В свете этого вопрос несколько двусмысленный:
Я по ошибке добавил файлы с помощью команды ...
Сценарий OP кажется первым (неотслеживаемый файл), мы хотим, чтобы «отмена» удаляла файл (а не только текущее содержимое) из отслеживаемых элементов. В этом случае можно запустить git rm --cached <file>
.
И мы могли бы также запустить git reset HEAD <file>
. В целом это предпочтительнее, потому что это работает в обоих сценариях: оно также отменяет действие, когда мы по ошибке добавили версию уже отслеживаемого элемента.
Но есть два предостережения.
Во-первых: существует (как указано в ответе) только один сценарий, в котором git reset HEAD
не работает, но git rm --cached
работает: новый репозиторий (без коммитов). Но на самом деле это практически не относящийся к делу случай.
Во-вторых: имейте в виду, что git reset HEAD
не может волшебным образом восстановить содержимое ранее кэшированного файла, он просто повторно синхронизирует его с HEAD. Если наша ошибочная git add
перезаписала предыдущую поэтапную незафиксированную версию, мы не сможем ее восстановить. Поэтому, строго говоря, мы не можем отменить [*].
Пример:
$ git init
$ echo "version 1" > file.txt
$ git add file.txt # First add of file.txt
$ git commit -m 'first commit'
$ echo "version 2" > file.txt
$ git add file.txt # Stage (don't commit) "version 2" of file.txt
$ git diff --cached file.txt
-version 1
+version 2
$ echo "version 3" > file.txt
$ git diff file.txt
-version 2
+version 3
$ git add file.txt # Oops we didn't mean this
$ git reset HEAD file.txt # Undo?
$ git diff --cached file.txt # No dif, of course. stage == HEAD
$ git diff file.txt # We have irrevocably lost "version 2"
-version 1
+version 3
Конечно, это не очень важно, если мы просто следуем обычному ленивому рабочему процессу, выполняя «git add» только для добавления новых файлов (случай 1), и мы обновляем новое содержимое с помощью команды commit, git commit -a
.
* (Edit: вышеизложенное практически верно, но все же могут быть некоторые слегка хакерские / запутанные способы восстановления изменений, которые были поставлены, но не зафиксированы, а затем перезаписаны - см. комментарии Йоханнеса Матокича и iolsmit) sup >
git cat-file
можно использовать для восстановления его содержимого.
- person Johannes Matokic; 06.12.2017
git add
- через git fsck --unreachable
, который перечислит все недостижимые объекты, которые вы затем можете проверить с помощью git show SHA-1_ID
или git fsck --lost-found
, которые будут ›записывать оборванные объекты в .git/lost-found/commit/
или .git/lost-found/other/
, в зависимости от типа. См. Также git fsck --help
- person iolsmit; 27.04.2018
Отменить уже добавленный файл довольно просто с помощью Git. Для сброса уже добавленных myfile.txt
используйте:
git reset HEAD myfile.txt
Объяснение:
После того, как вы разместили ненужный файл (ы), чтобы отменить, вы можете сделать git reset
. Head
- это заголовок вашего файла в локальном, а последний параметр - это имя вашего файла.
Я создал для вас более подробную информацию о шагах на изображении ниже, включая все шаги, которые могут произойти в этих случаях:
git rm --cached . -r
будет рекурсивно «отменить добавление» всего, что вы добавили из текущего каталога
git reset HEAD <file>
сказал бы fatal: Failed to resolve 'HEAD' as a valid ref.
- person Priya Ranjan Singh; 02.06.2013
Запустить
git gui
и удалите все файлы вручную или выбрав их все и нажав кнопку отключить от фиксации.
В Git есть команды для всех мыслимых действий, но ему нужны обширные знания, чтобы все делать правильно, и из-за этого он в лучшем случае нелогичен ...
Чем вы занимались раньше:
git add .
или git add <file>
.Что вы хотите:
Удалите файл из индекса, но оставьте его версионным и оставьте с незафиксированными изменениями в рабочей копии:
git reset HEAD <file>
Сбросьте файл в последнее состояние из HEAD, отменив изменения и удалив их из индекса:
# Think `svn revert <file>` IIRC.
git reset HEAD <file>
git checkout <file>
# If you have a `<branch>` named like `<file>`, use:
git checkout -- <file>
Это необходимо, поскольку git reset --hard HEAD
не работает с отдельными файлами.
Удалите <file>
из индекса и управления версиями, оставив файл без версий с изменениями в рабочей копии:
git rm --cached <file>
Полностью удалить <file>
из рабочей копии и управления версиями:
git rm <file>
reset head
отменяет ваши текущие изменения, но файл все еще отслеживается git. rm --cached
выводит файл из системы управления версиями, поэтому git больше не проверяет его на наличие изменений (а также удаляет в конечном итоге проиндексированные текущие изменения, сообщенные git предыдущим add
), но измененный файл будет храниться в вашей рабочей копии, то есть в вас файловую папку на жестком диске.
- person sjas; 15.08.2013
git reset HEAD <file>
носит временный характер - команда будет применена только к следующей фиксации, но git rm --cached <file>
будет отключена до тех пор, пока она не будет добавлена снова с помощью git add <file>
. Кроме того, git rm --cached <file>
означает, что если вы отправите эту ветку на удаленный компьютер, любой, кто потянет ветвь, получит ДЕЙСТВИТЕЛЬНО удаленный файл из своей папки.
- person DrewT; 10.08.2014
Вопрос четко не поставлен. Причина в том, что git add
имеет два значения:
git rm --cached file
.git reset HEAD file
.В случае сомнений используйте
git reset HEAD file
Потому что в обоих случаях он делает ожидаемую вещь.
Предупреждение: если вы сделаете git rm --cached file
для файла, который был изменен (файл, который ранее существовал в репозитории), то этот файл будет удален git commit
! Он по-прежнему будет существовать в вашей файловой системе, но если кто-то еще извлечет вашу фиксацию, файл будет удален из его рабочего дерева.
git status
сообщит вам, был ли файл новым или измененным:
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: my_new_file.txt
modified: my_modified_file.txt
git rm --cached somefile
. Я надеюсь, что этот ответ дойдет до страницы на видном месте, где он сможет защитить новичков от введения в заблуждение всеми ложными утверждениями.
- person Mark Amery; 31.10.2015
Если вы совершаете первоначальную фиксацию и не можете использовать git reset
, просто объявите «Git bankruptcy», удалите папку .git
и начните заново.
git add -A && git rm --cached EXCLUDEFILE && git commit -m 'awesome commit'
(Это также работает, когда нет предыдущих коммитов, из-за Failed to resolve 'HEAD'
проблемы)
- person ; 29.03.2013
Как и многие другие ответы, вы можете использовать git reset
НО:
Я нашел этот замечательный небольшой пост, который на самом деле добавляет команду Git (ну, псевдоним) для git unadd
: см. git unadd для получения подробной информации или ..
Просто,
git config --global alias.unadd "reset HEAD"
Теперь вы можете
git unadd foo.txt bar.txt
Альтернативно / напрямую:
git reset HEAD foo.txt bar.txt
Используйте git add -i
, чтобы удалить только что добавленные файлы из предстоящей фиксации. Пример:
Добавление файла, который вам не нужен:
$ git add foo
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: foo
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
# [...]#
Переход в интерактивное добавление для отмены добавления (команды, введенные в git здесь: «r» (возврат), «1» (первая запись в списке показывает возврат), «return» для выхода из режима возврата и «q» (покидать):
$ git add -i
staged unstaged path
1: +1/-0 nothing foo
*** Commands ***
1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked
5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp
What now> r
staged unstaged path
1: +1/-0 nothing [f]oo
Revert>> 1
staged unstaged path
* 1: +1/-0 nothing [f]oo
Revert>>
note: foo is untracked now.
reverted one path
*** Commands ***
1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked
5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp
What now> q
Bye.
$
Вот и все! Вот ваше доказательство, показывающее, что "foo" снова в списке неотслеживаемых:
$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
# [...]
# foo
nothing added to commit but untracked files present (use "git add" to track)
$
Для этого можно использовать git remove
или git rm
с флагом --cached
. Пытаться:
git help rm
git rm --cached ...
удалит файлы из репозитория git. Они по-прежнему будут существовать на вашем компьютере, но это ОЧЕНЬ отличается от неустановленных изменений в файле. Для тех, кто наткнулся на это, это неверный ответ на вопрос.
- person Addison; 17.12.2018
Вот способ избежать этой неприятной проблемы, когда вы начинаете новый проект:
git init
.В Git очень сложно делать git reset
, если у вас нет никаких коммитов. Если вы создаете крошечную начальную фиксацию только для того, чтобы иметь ее, после этого вы можете git add -A
и git reset
столько раз, сколько хотите, чтобы все было правильно.
Еще одно преимущество этого метода заключается в том, что если позже вы столкнетесь с проблемами, связанными с окончанием строки, и вам потребуется обновить все ваши файлы, это просто:
autocrlf
... Это не будет работать в каждом проекте, в зависимости от настроек.
- person sjas; 29.03.2013
git reset somefile
и git reset
оба работают до совершения первого коммита, сейчас. Так было с нескольких выпусков Git назад.
- person Mark Amery; 31.10.2015
Обратите внимание, что если вы не укажете ревизию, вам необходимо включить разделитель. Пример с моей консоли:
git reset <path_to_file>
fatal: ambiguous argument '<path_to_file>': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
git reset -- <path_to_file>
Unstaged changes after reset:
M <path_to_file>
(Git версии 1.7.5.4)
git reset <path>
, и он отлично работает без разделителя. Я также использую git 1.9.0. Может в старых версиях не работает?
- person ; 05.04.2014
Возможно, Git изменился с тех пор, как вы разместили свой вопрос.
$> git --version
git version 1.6.2.1
Теперь вы можете попробовать:
git reset HEAD .
Это должно быть то, что вы ищете.
Чтобы удалить новые файлы из области подготовки (и только в случае нового файла), как предложено выше:
git rm --cached FILE
Используйте rm --cached только для случайно добавленных новых файлов.
--cached
- действительно важная часть здесь.
- person takeshin; 12.04.2013
Чтобы сбросить каждый файл в определенной папке (и ее подпапках), вы можете использовать следующую команду:
git reset *
git status
, чтобы увидеть все, что осталось, и сбросить его вручную, т.е. git reset file
.
- person Zorayr; 07.05.2014
Используйте команду *
для одновременной обработки нескольких файлов:
git reset HEAD *.prj
git reset HEAD *.bmp
git reset HEAD *gdb*
и т.п.
.*
или .*.prj
- person Luc; 05.05.2014
Просто введите git reset
, он вернется обратно, и это похоже на то, что вы никогда не набирали git add .
с момента последней фиксации. Убедитесь, что вы сделали это раньше.
Предположим, я создаю новый файл newFile.txt
:
Предположим, я добавляю файл случайно, git add newFile.txt
:
Теперь я хочу отменить это добавление перед фиксацией git reset newFile.txt
:
Для конкретного файла:
- git сбросить my_file.txt
- git checkout my_file.txt
Для всех добавленных файлов:
- git сбросить.
- git checkout.
Примечание. checkout изменяет код в файлах и переходит в последнее обновленное (подтвержденное) состояние. сброс не меняет коды; он просто сбрасывает заголовок.
git reset <file>
и git checkout <file>
.
- person Trent; 23.01.2018
Как указывали другие в связанных вопросах (см. здесь, здесь, здесь, здесь, здесь, здесь и здесь), теперь вы можете отключить один файл с помощью:
git restore --staged <file>
и отключить все файлы (из корня репозитория) с помощью:
git restore --staged .
git restore
был представлен в июле 2019 г. и выпущен в версии 2.23.
Вместе с --staged
flag, он восстанавливает содержимое индекса (о чем здесь спрашивают).
При запуске git status
с поэтапными незафиксированными файлами, это то, что Git предлагает использовать для деактивации файлов (вместо git reset HEAD <file>
, как это было до v2.23).
Чтобы отменить git add
, используйте:
git reset filename
Также есть интерактивный режим:
git add -i
Выберите вариант 3, чтобы отменить добавление файлов. В моем случае я часто хочу добавить более одного файла, а в интерактивном режиме вы можете использовать такие числа для добавления файлов. Это займет все, кроме 4: 1, 2, 3 и 5.
Чтобы выбрать последовательность, просто введите 1-5, чтобы взять все от 1 до 5.
Эта команда откроет ваши изменения:
git reset HEAD filename.txt
Вы также можете использовать
git add -p
добавлять части файлов.
git add myfile.txt
# Это добавит ваш файл в список подлежащих фиксации
Совершенно противоположно этой команде,
git reset HEAD myfile.txt # This will undo it.
Итак, вы будете в предыдущем состоянии. Указанный будет снова в неотслеживаемом списке (предыдущее состояние).
Это сбросит вашу голову с указанным файлом. так что, если в вашей голове его нет, он просто сбросит его.
git reset filename.txt
Удалит файл с именем filename.txt из текущего индекса, области «собирается быть зафиксированным», ничего не меняя.
git reset filename.txt
Удалит файл с именем filename.txt из текущего индекса, области «собирается быть зафиксированным», ничего не меняя.
В Sourcetree вы можете легко сделать это через графический интерфейс. Вы можете проверить, какую команду Sourcetree использует для деактивации файла.
Я создал новый файл и добавил его в Git. Затем я отключил его с помощью графического интерфейса Sourcetree. Вот результат:
Удаление файлов [08/12/15 10:43] git -c diff.mnemonicprefix = false -c core.quotepath = false -c credential.helper = sourcetree reset -q - path / to / file / filename.java
Sourcetree использует reset
для деактивации новых файлов.
Одним из наиболее интуитивно понятных решений является использование Sourcetree.
Вы можете просто перетаскивать файлы из промежуточного и неустановленного
Команда git reset
помогает вам изменить либо промежуточную область, либо промежуточную область и рабочее дерево. Способность Git создавать коммиты в точности так, как вы хотите, означает, что иногда вам нужно отменить изменения, внесенные с помощью git add
.
Вы можете сделать это, позвонив git reset HEAD <file to change>
. У вас есть два варианта, чтобы полностью избавиться от изменений. git checkout HEAD <file(s) or path(s)>
- это быстрый способ отменить изменения в промежуточной области и рабочем дереве.
Однако будьте осторожны с этой командой, потому что она удаляет все изменения в вашем рабочем дереве. Git не знает об этих изменениях, поскольку они никогда не фиксировались. Невозможно вернуть эти изменения после выполнения этой команды.
Другая команда в вашем распоряжении - git reset --hard
. Это также разрушительно для вашего рабочего дерева - любые незафиксированные изменения или поэтапные изменения теряются после его запуска. Запуск git reset -hard HEAD
делает то же самое, что и git checkout HEAD
. Просто для работы не требуется файл или путь.
Вы можете использовать --soft
с git reset
. Он сбрасывает репозиторий на указанную вами фиксацию и выполняет все эти изменения. Никакие изменения, которые вы уже сделали, не затронуты, как и изменения в вашем рабочем дереве.
Наконец, вы можете использовать --mixed
для сброса рабочего дерева без внесения каких-либо изменений. Это также отменяет постановку любых изменений.
Вы можете отключить / отменить с помощью команды git или git с графическим интерфейсом.
Отдельный файл
git reset File.txt
Несколько файлов
git reset File1.txt File2.txt File3.txt
Пример. Предположим, вы по ошибке добавили Home.js, ListItem.js, Update.js и хотите отменить / сбросить =›
git reset src/components/home/Home.js src/components/listItem/ListItem.js src/components/update/Update.js
Тот же пример с использованием git GUI
git gui
открывает окно = ›Снимите отметку с файлов в разделе Поэтапные изменения (будут зафиксированы) < img src = "https://i.stack.imgur.com/cE4gI.png" alt = "введите описание изображения здесь" />
Вы можете использовать эту команду после git версии 2.23:
git restore --staged <filename>
Или вы можете использовать эту команду:
git reset HEAD <filename>
В первый раз, когда у меня возникла эта проблема, я обнаружил этот пост здесь, и из первого ответа я понял, что должен просто сделать git reset <filename>
. Все работало нормально.
В конце концов, внутри моей основной папки git оказалось несколько подпапок. Мне было легко просто git add .
добавить все файлы в подпапки, а затем git reset
несколько файлов, которые я не хотел добавлять.
Сейчас у меня много файлов и подпапок. Это утомительно git reset
по одному, но все же проще сначала просто git add .
, а затем сбросить несколько тяжелых / нежелательных, но полезных файлов и папок.
Я нашел следующий метод (который не записывается здесь или здесь) относительно легко. Надеюсь, это будет полезно:
Допустим, у вас есть следующая ситуация:
Folder/SubFolder1/file1.txt
Folder/SubFolder2/fig1.png
Folder/SubFolderX/fig.svg
Folder/SubFolder3/<manyfiles>
Folder/SubFolder4/<file1.py, file2.py, ..., file60.py, ...>
Вы хотите добавить все папки и файлы, но не fig1.png
, не SubFolderX
и не file60.py
, и список продолжает расти ...
Сначала создайте / создайте bash shell script
и дайте ему имя. Скажите, git_add.sh
:
Затем добавьте все пути ко всем папкам и файлам, которые вы хотите git reset
, перед которыми стоит git reset --
. Вы можете легко скопировать и вставить пути в сценарий git_add.sh
по мере роста вашего списка файлов. Скрипт git_add.sh
должен выглядеть так:
#!/bin/bash
git add .
git reset -- Folder/SubFolder2/fig1.png
git reset -- Folder/SubFolderX
git reset -- Folder/SubFolder4/file60.py
#!/bin/bash
важно. Затем выполните source git_add.sh
, чтобы запустить его. После этого вы можете сделать git commit -m "some comment"
, а затем git push -u origin master
, если вы уже настроили Bitbucket / Github.
Отказ от ответственности: я тестировал это только в Linux.
Если у вас много файлов и папок, которые вы всегда сохраняете в локальном репозитории git, но вы не хотите, чтобы git отслеживал изменения, когда вы делаете git add .
, например файлы видео и данных, вы должны научиться использовать _22 _ сильный>. Может быть, здесь.
source
файл, он не обязательно должен быть исполняемым.
- person Jonathan Leffler; 19.05.2021
.gitignore
для предотвращения добавления файлов и каталогов, которые не следует добавлять?
- person Jonathan Leffler; 08.06.2021
Перейти в ветку функций из источника
git checkout HEAD <file>
HEAD
илиhead
, теперь могут использовать@
вместоHEAD
. См. этот ответ (последний раздел), чтобы узнать, почему вы можете сделай это. - person   schedule 26.07.2013git checkout
не удаляет поэтапные изменения из индекса фиксации. Он только возвращает неустановленные изменения к последней зафиксированной ревизии - что, кстати, тоже не то, что я хочу, я хочу эти изменения, я просто хочу, чтобы они были в более позднем коммите. - person paxos1977   schedule 07.09.2016git reset <file_name>
. Для получения дополнительной информации обязательно ознакомьтесь с этой статьей. - person Nesha Zoric   schedule 07.05.2018git rm --cached <file>
отключает и отменяет отслеживание (помечается для удаления при следующей фиксации) данного файла, аgit reset HEAD <file>
просто отключает файл - person Dennis   schedule 31.01.2021