Git убрать файл из add

Обновлено: 04.07.2024

Я еще не бегал git commit . Есть ли способ отменить это, чтобы эти файлы не были включены в коммит?

Начиная с Git версии 1.8.4, все ответы ниже , что используют HEAD или head могут теперь использовать @ вместо HEAD вместо этого. Посмотрите этот ответ (последний раздел), чтобы узнать, почему вы можете это сделать. @ErikReppen git checkout не удаляет поэтапные изменения из индекса фиксации. Он только отменяет не поэтапные изменения последней зафиксированной ревизии - что, кстати, тоже не то, что я хочу, я хочу эти изменения, я просто хочу, чтобы они были в более поздней фиксации.

Вы можете отменить, git add прежде чем совершить с

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

Ты можешь использовать

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

В старых версиях Git вышеприведенные команды эквивалентны git reset HEAD <file> и git reset HEAD соответственно и завершатся неудачей, если HEAD не определено (потому что вы еще не сделали никаких коммитов в вашем хранилище) или неоднозначно (потому что вы создали ветвь с именем HEAD , что глупо что вы не должны делать). Это изменилось в Git 1.8.2 , поэтому в современных версиях Git вы можете использовать приведенные выше команды даже до того, как сделаете первый коммит:

«git reset» (без опций или параметров) используется для вывода ошибок, когда в вашей истории нет коммитов, но теперь он дает пустой индекс (для соответствия несуществующему коммиту вы даже не используете).

Конечно, это не настоящая отмена, потому что если неправильная git add версия перезаписала предыдущую подготовленную незафиксированную версию, мы не сможем ее восстановить. Я попытался уточнить это в своем ответе ниже. git reset HEAD *.ext где ext файлы с заданным расширением, которые вы хотите удалить. Для меня это было *.bmp & *.zip @Jonny, индекс (он же промежуточная область) содержит все файлы, а не только измененные файлы. Он «запускает жизнь» (когда вы извлекаете коммит или клонируете репо) как копию всех файлов в коммите, на которые указывает HEAD. Поэтому, если вы удаляете файл из index ( git rm --cached ), это означает, что вы готовитесь сделать коммит, который удаляет этот файл. git reset HEAD <filename> с другой стороны, скопирует файл из HEAD в индекс, чтобы при следующей фиксации не было внесено никаких изменений в этот файл. Я только что обнаружил, что есть git reset -p просто как git add -p . Это круто! Вы действительно можете восстановить перезаписанные ранее внесенные, но незафиксированные изменения, но не в удобной для пользователя форме и не на 100% безопасные (по крайней мере, ни один из них я не нашел): перейти к .git / objects, найти файлы, созданные в тот момент, когда git add вы хотите восстановить ( 61/3AF3. - > идентификатор объекта 613AF3. ), то git cat-file -p <object-id> (может быть, стоит восстановить несколько часов работы, но также и урок, который нужно совершать чаще . )

Когда я был новичком в этом, я впервые попробовал

Оказывается, это потому, что ссылка HEAD (ветвь?) Существует только после первого коммита. То есть, вы столкнетесь с той же проблемой новичка, что и я, если ваш рабочий процесс, такой как мой, будет выглядеть примерно так:

  1. перейдите в мой новый каталог проектов, чтобы опробовать Git, новую горячность
  2. git init
  3. git add .

. много дерьмовых свитков .

=> Черт, я не хотел добавлять все это.

google "отменить git add"

=> найти переполнение стека - ууу

=> fatal: Не удалось разрешить 'HEAD' в качестве действительного ссылки.

Кроме того, выясняется, что в списке рассылки зафиксирована ошибка против этой бесполезности.

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

И решение действительно заключается в использовании git rm --cached FILE .

Обратите внимание на предупреждения в другом месте здесь - git rm удаляет вашу локальную рабочую копию файла, но не, если вы используете --cached . Вот результат git help rm :

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

Я приступаю к использованию

удалить все и начать заново. Не сработало, хотя, потому что пока add . рекурсивно, оказывается, rm необходимо -r рекурсивно. Вздох.

Хорошо, теперь я вернулся к тому, с чего начал. В следующий раз я собираюсь использовать -n пробный прогон и посмотреть, что будет добавлено:

Я заархивировал все в безопасное место, прежде чем поверить git help rm в --cached то, что ничего не разрушено (и что, если я ошибся в этом).

Хах. Я следовал этому же процессу. За исключением того, что я сдался и сказал rm -rf .git , git init потому что я не доверял git rm --cached сохранить свою рабочую копию. Это говорит немного о том, как git все еще слишком сложен в некоторых местах. git unstage должна быть просто стандартная команда, мне все равно, могу ли я добавить ее в качестве псевдонима. git rm --cached <file> на самом деле правильный ответ, если это первоначальный импорт <file> в хранилище. Если вы пытаетесь отменить изменение файла, git reset - правильный ответ. Люди, которые говорят, что этот ответ неправильный, думают о другом вопросе. Это на самом деле будет работать, но только при первом коммите, где файл ранее не существовал или когда git add команда добавляла новые файлы, но не вносила изменения в существующие файлы. просто показывает, насколько неинтуитивен и запутанен мерзавец. вместо параллельных команд «отменить», вы должны выяснить, как их отменить. Как попытка высвободить ногу в быстром песке, а затем застрявшую руку, затем застрявшую вторую руку . каждая команда должна выполняться через графический интерфейс, с пунктами выпадающего меню для вариантов . Подумайте обо всем интерфейсе, рост производительности у нас был, но у нас есть этот беспорядок ретро интерфейс командной строки. Это не так, как программы git GUI делают это более интуитивно понятным.

Если вы введете:

Git расскажет вам, что ставится и т. Д., Включая инструкции о том, как выполнить расстановку:

Я нахожу, что Git довольно хорошо подталкивает меня делать правильные вещи в подобных ситуациях.

Большой! git reset HEAD <file> Один единственный , который будет работать в случае , если вы хотите убрать из буфера файла удаления Мой мерзавец версии 2.14.3 говорит, git reset HEAD чтобы нестандартно.

Для пояснения: git add перемещает изменения из текущего рабочего каталога в область подготовки (индекс).

Этот процесс называется постановкой . Таким образом, наиболее естественная команда этапа изменения (измененные файлы) является очевидным:

git add простой псевдоним для git stage

Жалко нет git unstage ни git unadd команд. Соответствующий труднее угадать или запомнить, но он довольно очевиден:

Мы можем легко создать псевдоним для этого:

И наконец, у нас есть новые команды:

Лично я использую даже более короткие псевдонимы:

«движется»? Это указало бы, что это ушло из рабочего каталога. Это не тот случай. На самом деле, git stage это псевдоним для git add , который является исторической командой, как на Git, так и на других SCM. Он был добавлен в декабре 2008 года с коммитом 11920d28da в «Git's git репозиторий», если можно так выразиться.

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

Это не о чем беспокоиться; файл действительно все еще находится в хранилище, но только как «свободный объект». Он не будет скопирован в другие репозитории (через клон, push), и пространство будет в конечном итоге восстановлено - хотя, возможно, не очень скоро. Если вы беспокоитесь, вы можете запустить:

Итак, что реальный откат от git add ?

git reset HEAD <file> ?

git rm --cached <file> ?

Собственно говоря, и если я не ошибаюсь нет .

git add не может быть отменено - безопасно, в общем.

Давайте вспомним сначала, что git add <file> самом деле делает:

Если <file> был ранее не отслеживаются , git add добавляет его в кэш , с его текущим содержанием.

Если <file> он уже отслежен , git add текущий контент (снимок, версия) сохраняется в кеше. В Git это действие по-прежнему называется add , а не просто update его), поскольку две разные версии (снимки) файла рассматриваются как два разных элемента: следовательно, мы действительно добавляем новый элемент в кеш, чтобы в конечном итоге совершено позже.

В свете этого вопрос несколько двусмысленный:

Я по ошибке добавил файлы с помощью команды .

Похоже, что сценарий OP является первым (неотслеживаемый файл), мы хотим, чтобы «отмена» удаляла файл (а не только текущее содержимое) из отслеживаемых элементов. Если это так, тогда все в порядке git rm --cached <file> .

И мы могли бы также бежать git reset HEAD <file> . В целом это предпочтительнее, потому что это работает в обоих сценариях: оно также отменяет действия, когда мы ошибочно добавили версию уже отслеженного элемента.

Но есть две оговорки.

Первый: существует (как указано в ответе) только один сценарий, в котором git reset HEAD не работает, но git rm --cached работает: новый репозиторий (без коммитов). Но на самом деле это практически неактуальный случай.

Второе: имейте в git reset HEAD виду, что не может волшебным образом восстановить ранее кэшированное содержимое файла, оно просто ресинхронизирует его из HEAD. Если наши заблуждения git add переписал предыдущую подготовленную незафиксированную версию, мы не сможем ее восстановить. Вот почему, строго говоря, мы не можем отменить [*].

Конечно, это не очень важно, если мы просто следуем обычному ленивому рабочему процессу выполнения 'git add' только для добавления новых файлов (случай 1), и мы обновляем новое содержимое с помощью команды commit, git commit -a command.

* (Редактировать: вышеупомянутое практически правильно, но все же могут быть несколько хакерские / запутанные способы восстановления изменений, которые были поставлены, но не зафиксированы, а затем перезаписаны - см. Комментарии Йоханнеса Матокича и iolsmit)

Строго говоря, есть способ восстановить уже подготовленный файл, который был заменен на git add. Как вы упомянули, git add создает объект git для этого файла, который станет свободным объектом не только при полном удалении файла, но и при перезаписи новым содержимым. Но нет команды для автоматического восстановления. Вместо этого файл должен быть идентифицирован и извлечен вручную или с помощью инструментов, написанных только для этого случая (libgit2 позволит это). Но это окупится только в том случае, если файл очень важный и большой и не может быть восстановлен путем редактирования предыдущей версии. Другой способ восстановить изменения, которые были организованы, но не зафиксированы, а затем перезаписаны , например, другим способом, 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

Отменить файл, который уже был добавлен, довольно просто с помощью Git. Для сброса myfile.txt , который уже был добавлен, используйте:

Объяснение:

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

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

В любой момент вам может потребоваться что-либо отменить. Здесь мы рассмотрим несколько основных способов отмены сделанных изменений. Будьте осторожны, не все операции отмены в свою очередь можно отменить! Это одна из редких областей Git, где неверными действиями можно необратимо удалить результаты своей работы.

Отмена может потребоваться, если вы сделали коммит слишком рано, например, забыв добавить какие-то файлы или комментарий к коммиту. Если вы хотите переделать коммит — внесите необходимые изменения, добавьте их в индекс и сделайте коммит ещё раз, указав параметр --amend :

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

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

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

Отмена индексации файла

Следующие два раздела демонстрируют как работать с индексом и изменениями в рабочем каталоге. Радует, что команда, которой вы определяете состояние этих областей, также подсказывает вам как отменять изменения в них. Например, вы изменили два файла и хотите добавить их в разные коммиты, но случайно выполнили команду git add * и добавили в индекс оба. Как исключить из индекса один из них? Команда git status напомнит вам:

Прямо под текстом «Changes to be committed» говорится: используйте git reset HEAD <file>…​ для исключения из индекса. Давайте последуем этому совету и отменим индексирование файла CONTRIBUTING.md :

Команда выглядит несколько странно, но — работает! Файл CONTRIBUTING.md изменен, но больше не добавлен в индекс.

Команда git reset может быть опасной если вызвать её с параметром --hard . В приведенном примере файл не был затронут, следовательно команда относительно безопасна.

На текущий момент этот магический вызов — всё, что вам нужно знать о команде git reset . Мы рассмотрим в деталях что именно делает reset и как с её помощью делать действительно интересные вещи в разделе Раскрытие тайн reset главы 7.

Отмена изменений в файле

Что делать, если вы поняли, что не хотите сохранять свои изменения файла CONTRIBUTING.md ? Как можно просто отменить изменения в нём — вернуть к тому состоянию, которое было в последнем коммите (или к начальному после клонирования, или еще как-то полученному)? Нам повезло, что git status подсказывает и это тоже.

В выводе команды из последнего примера список изменений выглядит примерно так:

Здесь явно сказано как отменить существующие изменения. Давайте так и сделаем:

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

Важно понимать, что git checkout -- <file> — опасная команда. Все локальные изменения в файле пропадут — Git просто заменит его версией из последнего коммита. Ни в коем случае не используйте эту команду, если вы не уверены, что изменения в файле вам не нужны.

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

Помните, все что попало в коммит почти всегда Git может восстановить. Можно восстановить даже коммиты из веток, которые были удалены, или коммиты, перезаписанные параметром --amend (см. Восстановление данных). Но всё, что не было включено в коммит и потеряно — скорее всего, потеряно навсегда.

Отмена действий с помощью git restore

Git версии 2.23.0 представил новую команду: git restore . По сути, это альтернатива git reset, которую мы только что рассмотрели. Начиная с версии 2.23.0, Git будет использовать git restore вместо git reset для многих операций отмены.

Давайте проследим наши шаги и отменим действия с помощью git restore вместо git reset .

Отмена индексации файла с помощью git restore

В следующих двух разделах показано, как работать с индексом и изменениями рабочей копии с помощью git restore . Приятно то, что команда, которую вы используете для определения состояния этих двух областей, также напоминает вам, как отменить изменения в них. Например, предположим, что вы изменили два файла и хотите зафиксировать их как два отдельных изменения, но случайно набираете git add * и индексируете их оба. Как вы можете убрать из индекса один из двух? Команда git status напоминает вам:

Прямо под текстом «Changes to be committed», написано использовать git restore --staged <file> …​ для отмены индексации файла. Итак, давайте воспользуемся этим советом, чтобы убрать из индекса файл CONTRIBUTING.md :

Файл CONTRIBUTING.md изменен, но снова не индексирован.

Откат измененного файла с помощью git restore

Что, если вы поймете, что не хотите сохранять изменения в файле CONTRIBUTING.md ? Как легко его откатить — вернуть обратно к тому, как он выглядел при последнем коммите (или изначально клонирован, или каким-либо образом помещён в рабочий каталог)? К счастью, git status тоже говорит, как это сделать. В выводе последнего примера, неиндексированная область выглядит следующим образом:

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

Важно понимать, что git restore <file> — опасная команда. Любые локальные изменения, внесенные в этот файл, исчезнут — Git просто заменит файл последней зафиксированной версией. Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохраненные локальные изменения.

Если вы хотите получше узнать те части Git, про которые раньше боялись спросить, то этот список для вас. Тут собраны наиболее типичные ситуации и способы их решения как из личного опыта автора, так и собранные по всему Интернету.

Ошибка в комментарии к коммиту

git commit --amend

Как отменить последний коммит?

Можно использовать git reset , вот так:

git reset --hard HEAD

1 означает один коммит до HEAD, т.е. до текущего положения. Стоит заметить, что это «ядерный» способ, который отменит все изменения. Если вам нужно сохранить всё, что вы сделали, но еще не успели закоммитить, используйте:

git reset --soft HEAD

Удалить ветку на сервере

git push origin --delete имя_ветки

В чём разница между «git pull» и «git fetch»?

git pull — это, по сути, git fetch , после которого сразу же следует git merge . git fetch получает изменения с сервера и сохраняет их в refs/remotes/ . Это никак не влияет на локальные ветки и текущие изменения. А git pull вливает все эти изменения в локальную копию.

Как отменить «git add» до коммита?

Вы выполнили git add имя_файла случайно и хотите отменить добавление файла. Если коммит ещё не был сделан, то поможет:

git reset имя_файла

Как разрешать конфликты слияния?

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

Удалить все локальные файлы и директории, которые не отслеживает Git, из вашей текущей копии

Осторожно! Лучше сделайте перед этим бэкап.

Клонировать все ветки с сервера

Скорее всего, вы это уже сделали, а ветки просто скрыты. Вот команда, чтобы показать их:

Можно использовать git checkout origin/имя_ветки , чтобы посмотреть на нужную ветку. Или git checkout -b имя_ветки origin/имя_ветки , чтобы создать локальную ветку, соответствующую удалённой.

Переименовать локальную ветку

git branch -m oldname newname

Вернуться к любому коммиту

Можно использовать git reset , как показано ранее. Это будет означать, что вы хотите навсегда вернуться к тому состоянию, в котором вы были, а не просто посмотреть на него (для этого надо сделать checkout). Идентификатор коммита должен быть такой, какой прописан в выводе команды git log .

git reset --hard идентификатор_коммита

Ещё раз повторим: команда отменит все текущие изменения, так что убедитесь, что вам это действительно нужно. Или используйте --soft вместо --hard.

Удалить подмодуль (submodule)

Создание подмодулей используется довольно редко, но иногда они всё-таки встречаются. Вот, что вам нужно:

git submodule deinit submodulename
git rm submodulename
git rm --cached submodulename
rm -rf .git/modules/submodulename

Перезаписать локальные файлы во время git pull

Вам снова поможет git reset :

git fetch --all
git reset --hard origin/master

Как добавить пустую директорию в репозиторий?

Никак! Такая возможность просто не поддерживается, т.к. считается, что вам это не нужно. Но есть один трюк. Можно создать файл .gitignore в нужной директории со следующим содержимым:

Экспортирование исходников аналогично «svn export»

Используйте git archive , например, так:

git archive --format zip --output /путь/к/файлу/файл.zip master

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

Отмена Git Add

Один из самых распространенных вопросов в сообществе Git звучит так: “Как откатить git add перед коммитом?” Вы можете отменить действия над конкретным файлом или все внесенные изменения.

Решение, которое потребуется для этого, весьма простое. Чтобы откатить один файл, просто вызовите команду git reset :

Для отмены всех изменений запустите следующее:

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

Как откатить Git Merge

Здесь на помощь приходит еще одна команда класса “отмена”: git revert . Начнем с того, что переключимся на мастер-ветку, используя команду git checkout :

Следующий шаг — запустить команду git log , чтобы получить ID сделанного объединения:

Затем вернитесь к упомянутому коммиту, выполнив следующее:

Используя -m 1 , вы даете Git указание: вернуться к первому родительскому элементу мастер-ветки, куда был совершен коммит объединения. Например, использование -m 2 сказало бы Git вернуться к первому родительскому элементу ветки, откуда пришел запрос на объединение.

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

Как откатить Git Reset

Предлагаем суперкороткий способ отменить команду git reset:

Следом можно запустить команду git reflog , чтобы просмотреть журнал всех обновлений (т.е. переключение веток, сброс, коммит, объединение).

Отмена последних коммитов в Git

Существует несколько методов для отмены git commit . Давайте рассмотрим их по очереди.

Команду git reset можно использовать для отмены внесенных изменений:

x введите число. Например, если вы укажете

4 , то команда повлияет на четвертый снизу коммит. Если вы не укажете никакое конкретно число, git reset — soft HEAD применится к последнему коммиту.

Когда вы используете команду git reset — soft HEAD , то просто отменяете последний коммит, при этом внесенные изменения останутся в вашем рабочем дереве и в вашем индексе. Поэтому git commit создаст в будущем коммит с теми же самыми изменениями, которые вы “обнулили” перед этим.

Другой метод — это команда git revert HEAD

x ( git reset — hard commit hash ), которая отменяет изменения, указанные последним коммитом в HEAD , и создает новый с возвращенными изменениями:

Этот метод лучше всего работает в случае с общими публичными репозиториями.

Отмена Git Rebase

Допустим, вы выполнили команду git rebase в локальной ветке git и отправили ее в удаленную ветку. Следом вы поняли, что это не отвечает вашим ожиданиям, и захотели отменить сделанное.

Самый простой способ — найти главный коммит вашей ветки, запустив команду:

Следом необходимо установить туда текущую ветку, воспользовавшись git reset .

В данном случае старым коммитом был HEAD5 .

Заключение

Вот и все о том, как вы можете отменить наиболее часто используемые команды в Git. Хоть никакой традиционной команды отмены и нет, другие команды git могут помочь вам откатить то, что вы могли сделать по ошибке.

Читайте также: