Изменения которые будут включены в коммит используйте git reset head файл чтобы убрать из индекса
В любой момент вам может потребоваться что-либо отменить. Здесь мы рассмотрим несколько основных способов отмены сделанных изменений. Будьте осторожны, не все операции отмены можно отменить! Это одна из редких областей Git, где неверными действиями можно необратимо удалить результаты своей работы.
Отмена может потребоваться, если вы сделали коммит слишком рано, например, забыв добавить какие-то файлы или комментарий к коммиту. Если вы хотите переделать коммит – внесите необходимые изменения, добавьте их в индекс и сделайте коммит ещё раз, указав параметр --amend :
Например, если вы сделали коммит и поняли, что забыли проиндексировать изменения в файле, который хотели добавить в коммит, то можно сделать следующее:
В итоге получится единый коммит – второй коммит заменит результаты первого.
Примечание
Очень важно понимать, что когда вы вносите правки в последний коммит, вы не столько исправляете его, сколько заменяете новым, который полностью его перезаписывает. В результате всё выглядит так, будто первоначальный коммит никогда не существовал, а также он больше не появится в истории вашего репозитория.
Отмена индексации файла
Следующие два раздела демонстрируют как работать с индексом и изменениями в рабочем каталоге. Радует, что команда, которой вы определяете состояние этих областей, также подсказывает вам, как отменять изменения в них. Например, вы изменили два файла и хотите добавить их в разные коммиты, но случайно выполнили команду git add * и добавили в индекс оба. Как исключить из индекса один из них? Команда git status напомнит вам:
Прямо под текстом « Changes to be committed » говорится: используйте git reset HEAD … для исключения из индекса. Давайте последуем этому совету и отменим индексирование файла CONTRIBUTING.md :
Команда выглядит несколько странно, но – работает! Файл CONTRIBUTING.md изменен, но больше не добавлен в индекс.
Примечание
Команда git reset может быть опасной, если её вызвать с параметром --hard . В приведенном примере файл не был затронут, следовательно команда относительно безопасна.
На текущий момент этот магический вызов – всё, что вам нужно знать о команде git reset . Подробнее мы рассмотрим, что именно делает reset , и как с её помощью делать действительно интересные вещи в разделе «Раскрытие тайн reset » главы 7.
Назначение команды reset
Команда reset становится более понятной, если рассмотреть её с учётом вышеизложенного.
В следующих примерах предположим, что мы снова изменили файл file.txt и закоммитили его в третий раз. Так что наша история теперь выглядит так:
Давайте теперь внимательно проследим, что именно происходит при вызове reset . Эта команда простым и предсказуемым способом управляет тремя деревьями, существующими в Git. Она выполняет три основных операции.
Шаг 1: Перемещение указателя HEAD
Первое, что сделает reset — переместит то, на что указывает HEAD. Обратите внимание, изменяется не сам HEAD (что происходит при выполнении команды checkout ); reset перемещает ветку, на которую указывает HEAD. Таким образом, если HEAD указывает на ветку master (то есть вы сейчас работаете с веткой master ), выполнение команды git reset 9e5e6a4 сделает так, что master будет указывать на 9e5e6a4 .
Не важно с какими опциями вы вызвали команду reset с указанием коммита ( reset также можно вызывать с указанием пути), она всегда будет пытаться сперва сделать данный шаг. При вызове reset --soft на этом выполнение команды и остановится.
Теперь взгляните на диаграмму и постарайтесь разобраться, что случилось: фактически была отменена последняя команда git commit . Когда вы выполняете git commit , Git создает новый коммит и перемещает на него ветку, на которую указывает HEAD. Если вы выполняете reset на HEAD~ (родителя HEAD), то вы перемещаете ветку туда, где она была раньше, не изменяя при этом ни Индекс, ни Рабочий Каталог. Вы можете обновить Индекс и снова выполнить git commit , таким образом добиваясь того же, что делает команда git commit --amend (смотрите Изменение последнего коммита).
Шаг 2: Обновление Индекса (--mixed)
Заметьте, если сейчас вы выполните git status , то увидите отмеченные зелёным цветом изменения между Индексом и новым HEAD.
Следующим, что сделает reset , будет обновление Индекса содержимым того снимка, на который указывает HEAD.
Если вы указали опцию --mixed , выполнение reset остановится на этом шаге. Такое поведение также используется по умолчанию, поэтому если вы не указали совсем никаких опций (в нашем случае git reset HEAD~ ), выполнение команды также остановится на этом шаге.
Снова взгляните на диаграмму и постарайтесь разобраться, что произошло: отменен не только ваш последний commit , но также и добавление в индекс всех файлов. Вы откатились назад до момента выполнения команд git add и git commit .
Шаг 3: Обновление Рабочего Каталога (--hard)
Третье, что сделает reset — это приведение вашего Рабочего Каталога к тому же виду, что и Индекс. Если вы используете опцию --hard , то выполнение команды будет продолжено до этого шага.
Давайте разберемся, что сейчас случилось. Вы отменили ваш последний коммит, результаты выполнения команд git add и git commit , а также все изменения, которые вы сделали в рабочем каталоге.
Важно отметить, что только указание этого флага ( --hard ) делает команду reset опасной, это один из немногих случаев, когда Git действительно удаляет данные. Все остальные вызовы reset легко отменить, но при указании опции --hard команда принудительно перезаписывает файлы в Рабочем Каталоге. В данном конкретном случае, версия v3 нашего файла всё ещё остаётся в коммите внутри базы данных Git и мы можем вернуть её, просматривая наш reflog , но если вы не коммитили эту версию, Git перезапишет файл и её уже нельзя будет восстановить.
Резюме
Команда reset в заранее определённом порядке перезаписывает три дерева Git, останавливаясь тогда, когда вы ей скажете:
Перемещает ветку, на которую указывает HEAD (останавливается на этом, если указана опция --soft )
Делает Индекс таким же как и HEAD (останавливается на этом, если не указана опция --hard )
Делает Рабочий Каталог таким же как и Индекс.
Отмена действий с помощью git restore
Git версии 2.23.0 представил новую команду: git restore . По сути, это альтернатива git reset , которую мы только что рассмотрели. Начиная с версии 2.23.0, Git будет использовать git restore , вместо git reset , для многих операций отмены.
Давайте проследим наши шаги и отменим действия с помощью git restore вместо git reset .
Сравнение с checkout
Наконец, вы можете задаться вопросом, в чем же состоит отличие между checkout и reset . Как и reset , команда checkout управляет тремя деревьями Git, и также её поведение зависит от того указали ли вы путь до файла или нет.
Без указания пути
Команда git checkout [branch] очень похожа на git reset --hard [branch] , в процессе их выполнения все три дерева изменяются так, чтобы выглядеть как [branch] . Но между этими командами есть два важных отличия.
Во-первых, в отличие от reset --hard , команда checkout бережно относится к рабочему каталогу, и проверяет, что она не трогает файлы, в которых есть изменения. В действительности, эта команда поступает немного умнее — она пытается выполнить в Рабочем Каталоге простые слияния так, чтобы все файлы, которые вы не изменяли, были обновлены. С другой стороны, команда reset --hard просто заменяет всё целиком, не выполняя проверок.
Второе важное отличие заключается в том, как эти команды обновляют HEAD. В то время как reset перемещает ветку, на которую указывает HEAD, команда checkout перемещает сам HEAD так, чтобы он указывал на другую ветку.
Например, пусть у нас есть ветки master и develop , которые указывают на разные коммиты и мы сейчас находимся на ветке develop (то есть HEAD указывает на неё). Если мы выполним git reset master , сама ветка develop станет ссылаться на тот же коммит, что и master . Если мы выполним git checkout master , то develop не изменится, но изменится HEAD. Он станет указывать на master .
Итак, в обоих случаях мы перемещаем HEAD на коммит A, но важное отличие состоит в том, как мы это делаем. Команда reset переместит также и ветку, на которую указывает HEAD, а checkout перемещает только сам HEAD.
С указанием пути
Другой способ выполнить checkout состоит в том, чтобы указать путь до файла. В этом случае, как и для команды reset , HEAD не перемещается. Эта команда как и git reset [branch] file обновляет файл в индексе версией из коммита, но дополнительно она обновляет и файл в рабочем каталоге. То же самое сделала бы команда git reset --hard [branch] file (если бы reset можно было бы так запускать) — это небезопасно для рабочего каталога и не перемещает HEAD.
Также как git reset и git add , команда checkout принимает опцию --patch для того, чтобы позволить вам избирательно откатить изменения содержимого файла по частям.
Три дерева
Разобраться с командами reset и checkout будет проще, если считать, что Git управляет содержимым трёх различных деревьев. Здесь под «деревом» мы понимаем «набор файлов», а не специальную структуру данных. (В некоторых случаях индекс ведет себя не совсем так, как дерево, но для наших текущих целей его проще представлять именно таким.)
В своих обычных операциях Git управляет тремя деревьями:
Снимок последнего коммита, родитель следующего
Снимок следующего намеченного коммита
Указатель HEAD
HEAD — это указатель на текущую ветку, которая, в свою очередь, является указателем на последний коммит, сделанный в этой ветке. Это значит, что HEAD будет родителем следующего созданного коммита. Как правило, самое простое считать HEAD снимком вашего последнего коммита.
На самом деле, довольно легко увидеть, что представляет из себя этот снимок. Ниже приведён пример получения содержимого каталога и контрольных сумм для каждого файла в HEAD:
Команды cat-file и ls-tree являются «служебными» (plumbing) командами, которые используются внутри системы и не требуются при ежедневной работе, но они помогают нам разобраться, что же происходит на самом деле.
Индекс
Индекс — это ваш следующий намеченный коммит. Мы также упоминали это понятие как «область подготовленных изменений» Git — то, что Git просматривает, когда вы выполняете git commit .
Git заполняет индекс списком изначального содержимого всех файлов, выгруженных в последний раз в ваш рабочий каталог. Затем вы заменяете некоторые из таких файлов их новыми версиями и команда git commit преобразует изменения в дерево для нового коммита.
Повторим, здесь мы используем служебную команду ls-files , которая показывает вам, как выглядит сейчас ваш индекс.
Технически, индекс не является древовидной структурой, на самом деле, он реализован как сжатый список (flattened manifest) — но для наших целей такого представления будет достаточно.
Рабочий Каталог
Наконец, у вас есть рабочий каталог. Два других дерева сохраняют свое содержимое эффективным, но неудобным способом внутри каталога .git . Рабочий Каталог распаковывает их в настоящие файлы, что упрощает для вас их редактирование. Считайте Рабочий Каталог песочницей, где вы можете опробовать изменения перед их коммитом в индекс (область подготовленных изменений) и затем в историю.
Технологический процесс
Основное предназначение Git — это сохранение снимков последовательно улучшающихся состояний вашего проекта, путём управления этими тремя деревьями.
Давайте рассмотрим этот процесс: пусть вы перешли в новый каталог, содержащий один файл. Данную версию этого файла будем называть v1 и изображать голубым цветом. Выполним команду git init , которая создаст Git-репозиторий, у которого ссылка HEAD будет указывать на ещё несуществующую ветку ( master пока не существует).
На данном этапе только дерево Рабочего Каталога содержит данные.
Теперь мы хотим закоммитить этот файл, поэтому мы используем git add для копирования содержимого Рабочего Каталога в Индекс.
Затем, мы выполняем команду git commit , которая сохраняет содержимое Индекса как неизменяемый снимок, создает объект коммита, который указывает на этот снимок, и обновляет master так, чтобы он тоже указывал на этот коммит.
Если сейчас выполнить git status , то мы не увидим никаких изменений, так как все три дерева одинаковые.
Теперь мы хотим внести изменения в файл и закоммитить его. Мы пройдём через всё ту же процедуру; сначала мы отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла v2 и обозначать красным цветом.
Если сейчас мы выполним git status , то увидим, что файл выделен красным в разделе «Изменения, не подготовленные к коммиту», так как его представления в Индексе и Рабочем Каталоге различны. Затем мы выполним git add для этого файла, чтобы поместить его в Индекс.
Если сейчас мы выполним git status , то увидим, что этот файл выделен зелёным цветом в разделе «Изменения, которые будут закоммичены», так как Индекс и HEAD различны — то есть, наш следующий намеченный коммит сейчас отличается от нашего последнего коммита. Наконец, мы выполним git commit , чтобы окончательно совершить коммит.
Сейчас команда git status не показывает ничего, так как снова все три дерева одинаковые.
Переключение веток и клонирование проходят через похожий процесс. Когда вы переключаетесь (checkout) на ветку, HEAD начинает также указывать на новую ветку, ваш Индекс замещается снимком коммита этой ветки, и затем содержимое Индекса копируется в ваш Рабочий Каталог.
EXAMPLES
You are happily working on something, and find the changes in these files are in good order. You do not want to see them when you run git diff , because you plan to work on other files and changes with these files are distracting.
Somebody asks you to pull, and the changes sound worthy of merging.
However, you already dirtied the index (i.e. your index does not match the HEAD commit). But you know the pull you are going to make does not affect frotz.c or filfre.c , so you revert the index changes for these two files. Your changes in working tree remain there.
Then you can pull and merge, leaving frotz.c and filfre.c changes still in the working tree.
This is most often done when you remembered what you just committed is incomplete, or you misspelled your commit message, or both. Leaves working tree as it was before "reset".
Make corrections to working tree files.
"reset" copies the old head to .git/ORIG_HEAD ; redo the commit by starting with its log message. If you do not need to edit the message further, you can give -C option instead.
See also the --amend option to git-commit[1].
You have made some commits, but realize they were premature to be in the master branch. You want to continue polishing them in a topic branch, so create topic/wip branch off of the current HEAD .
Rewind the master branch to get rid of those three commits.
Switch to topic/wip branch and keep working.
The last three commits ( HEAD , HEAD^ , and HEAD~2 ) were bad and you do not want to ever see them again. Do not do this if you have already given these commits to somebody else. (See the "RECOVERING FROM UPSTREAM REBASE" section in git-rebase[1] for the implications of doing so.)
Try to update from the upstream resulted in a lot of conflicts; you were not ready to spend a lot of time merging right now, so you decide to do that later.
"pull" has not made merge commit, so git reset --hard which is a synonym for git reset --hard HEAD clears the mess from the index file and the working tree.
Merge a topic branch into the current branch, which resulted in a fast-forward.
But you decided that the topic branch is not ready for public consumption yet. "pull" or "merge" always leaves the original tip of the current branch in ORIG_HEAD , so resetting hard to it brings your index file and the working tree back to that state, and resets the tip of the branch to that commit.
Even if you may have local modifications in your working tree, you can safely say git pull when you know that the change in the other branch does not overlap with them.
After inspecting the result of the merge, you may find that the change in the other branch is unsatisfactory. Running git reset --hard ORIG_HEAD will let you go back to where you were, but it will discard your local changes, which you do not want. git reset --merge keeps your local changes.
Suppose you are interrupted by an urgent fix request while you are in the middle of a large change. The files in your working tree are not in any shape to be committed yet, but you need to get to the other branch for a quick bugfix.
This commit will get blown away so a throw-away log message is OK.
This removes the WIP commit from the commit history, and sets your working tree to the state just before you made that snapshot.
At this point the index file still has all the WIP changes you committed as snapshot WIP. This updates the index to show your WIP files as uncommitted.
Suppose you have added a file to your index, but later decide you do not want to add it to your commit. You can remove the file from the index while keeping your changes with git reset.
This removes the file from the index while keeping it in the working directory.
This commits all other changes in the index.
Adds the file to the index again.
Suppose you are working on something and you commit it, and then you continue working a bit more, but now you think that what you have in your working tree should be in another branch that has nothing to do with what you committed previously. You can start a new branch and reset it while keeping the changes in your working tree.
This commits your first edits in branch1 .
In the ideal world, you could have realized that the earlier commit did not belong to the new topic when you created and switched to branch2 (i.e. git switch -c branch2 start ), but nobody is perfect.
But you can use reset --keep to remove the unwanted commit after you switched to branch2 .
Suppose that you have created lots of logically separate changes and committed them together. Then, later you decide that it might be better to have each logical chunk associated with its own commit. You can use git reset to rewind history without changing the contents of your local files, and then successively use git add -p to interactively select which hunks to include into each commit, using git commit -c to pre-populate the commit message.
First, reset the history back one commit so that we remove the original commit, but leave the working tree with all the changes. The -N ensures that any new files added with HEAD are still marked so that git add -p will find them.
Next, we interactively select diff hunks to add using the git add -p facility. This will ask you about each diff hunk in sequence and you can use simple commands such as "yes, include this", "No don’t include this" or even the very powerful "edit" facility.
Once satisfied with the hunks you want to include, you should verify what has been prepared for the first commit by using git diff --cached . This shows all the changes that have been moved into the index and are about to be committed.
Next, commit the changes stored in the index. The -c option specifies to pre-populate the commit message from the original message that you started with in the first commit. This is helpful to avoid retyping it. The HEAD@ is a special notation for the commit that HEAD used to be at prior to the original reset commit (1 change ago). See git-reflog[1] for more details. You may also use any other valid commit reference.
You can repeat steps 2-4 multiple times to break the original code into any number of commits.
Now you’ve split out many of the changes into their own commits, and might no longer use the patch mode of git add , in order to select all remaining uncommitted changes.
Once again, check to verify that you’ve included what you want to. You may also wish to verify that git diff doesn’t show any remaining changes to be committed later.
Перед тем, как перейти к более специализированными утилитам, давайте поговорим о reset и checkout . Эти команды кажутся самыми непонятными из всех, которые есть в Git, когда вы в первый раз сталкиваетесь с ними. Они делают так много, что попытки по-настоящему их понять и правильно использовать кажутся безнадёжными. Для того, чтобы всё же достичь этого, мы советуем воспользоваться простой аналогией.
console
Просто удаляем последний коммит из ветки, в которой находимся. Указатель ветки перейдет на предыдущий. Все изменения, внесённые в этом коммите, останутся в рабочей области проекта (т.е. в файлах на диске).
То же самое, плюс все изменения последнего коммита будут добавлены в индекс. Можно сразу сделать из них новый коммит.
То же самое можно сделать в Android Studio: View → Tool Windows → Version Control , вкладка Log , там ПКМ по предыдущему коммиту и Reset Current Branch to Here (выбрать Soft)
Последний коммит был сделан необдуманно (вспомнилось, что там есть пара проблем, которые не хотелось бы увековечивать)
Этот коммит также можно отредактировать заменить новым. Просто добавьте в индекс все нужные файлы в том состоянии, которое достойно отлития в бронзе и высечения в мраморе.
Ключ --amend сообщает git о том, что нужно не создавать новый коммит, а пересобрать последний. Это нельзя назвать редактированием, т.к. коммиты - неизменяемые (immutable) объекты, как строки в Java.
Ключ --no-edit сообщает git о том, что мы не хотим менять комментарий последнего коммита. Вместо него можно задать новый комментарий: git commit --amend -m'bla bla bla'
Для этого тоже есть графический способ: специальная галочка в окне создания коммита:
Reset с указанием пути
Основной форме команды reset (без опций --soft и --hard ) вы также можете передавать путь, с которым она будет оперировать. В этом случае, reset пропустит первый шаг, а на остальных будет работать только с указанным файлом или набором файлов. Первый шаг пропускается, так как HEAD является указателем и не может ссылаться частично на один коммит, а частично на другой. Но Индекс и Рабочий Каталог могут быть изменены частично, поэтому reset выполняет шаги 2 и 3.
Итак, предположим вы выполнили команду git reset file.txt . Эта форма записи (так как вы не указали ни SHA-1 коммита, ни ветку, ни опций --soft или --hard ) является сокращением для git reset --mixed HEAD file.txt , которая:
Перемещает ветку, на которую указывает HEAD (будет пропущено)
Делает Индекс таким же как и HEAD (остановится здесь)
То есть, фактически, она копирует файл file.txt из HEAD в Индекс.
Это создает эффект отмены индексации файла. Если вы посмотрите на диаграммы этой команды и команды git add , то увидите, что их действия прямо противоположные.
Именно поэтому в выводе git status предлагается использовать такую команду для отмены индексации файла. (Смотрите подробности в Отмена индексации файла.)
Мы легко можем заставить Git «брать данные не из HEAD», указав коммит, из которого нужно взять версию этого файла. Для этого мы должны выполнить следующее git reset eb43bf file.txt .
Можно считать, что, фактически, мы в Рабочем Каталоге вернули содержимое файла к версии v1, выполнили для него git add , а затем вернули содержимое обратно к версии v3 (в действительности все эти шаги не выполняются). Если сейчас мы выполним git commit , то будут сохранены изменения, которые возвращают файл к версии v1, но при этом файл в Рабочем Каталоге никогда не возвращался к такой версии.
Заметим, что как и команде git add , reset можно указывать опцию --patch для отмены индексации части содержимого. Таким способом вы можете избирательно отменять индексацию или откатывать изменения.
2 ответа 2
Откат измененного файла с помощью git restore
Что, если вы поймете, что не хотите сохранять изменения в файле CONTRIBUTING.md ? Как легко его откатить – вернуть обратно к тому, как он выглядел при последнем коммите (или изначально клонирован, или каким-либо образом помещён в рабочий каталог)? К счастью, git status тоже говорит, как это сделать. В выводе последнего примера, неиндексированная область выглядит следующим образом:
Это довольно недвусмысленно говорит, как отменить сделанные вами изменения. Давайте сделаем то, что написано:
Важно
Важно понимать, что git restore – опасная команда. Любые локальные изменения, внесенные в этот файл, исчезнут – Git просто заменит файл последней зафиксированной версией. Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохраненные локальные изменения.
В любой момент вам может потребоваться что-либо отменить. Здесь мы рассмотрим несколько основных способов отмены сделанных изменений. Будьте осторожны, не все операции отмены в свою очередь можно отменить! Это одна из редких областей Git, где неверными действиями можно необратимо удалить результаты своей работы.
Отмена может потребоваться, если вы сделали коммит слишком рано, например, забыв добавить какие-то файлы или комментарий к коммиту. Если вы хотите переделать коммит — внесите необходимые изменения, добавьте их в индекс и сделайте коммит ещё раз, указав параметр --amend :
Например, если вы сделали коммит и поняли, что забыли проиндексировать изменения в файле, который хотели добавить в коммит, то можно сделать следующее:
В итоге получится единый коммит — второй коммит заменит результаты первого.
Очень важно понимать, что когда вы вносите правки в последний коммит, вы не столько исправляете его, сколько заменяете новым, который полностью его перезаписывает. В результате всё выглядит так, будто первоначальный коммит никогда не существовал, а так же он больше не появится в истории вашего репозитория.
Отмена изменений в файле
Что делать, если вы поняли, что не хотите сохранять свои изменения файла CONTRIBUTING.md ? Как можно просто отменить изменения в нём – вернуть к тому состоянию, которое было в последнем коммите (или к начальному после клонирования, или еще как-то полученному)? Нам повезло, что git status подсказывает и это тоже.
В выводе команды из последнего примера список изменений выглядит примерно так:
Здесь явно сказано, как отменить существующие изменения. Давайте так и сделаем:
Как видите, откат изменений выполнен.
Важно
Важно понимать, что git checkout -- – опасная команда. Все локальные изменения в файле пропадут – Git просто заменит его версией из последнего коммита. Ни в коем случае не используйте эту команду, если вы не уверены, что изменения в файле вам не нужны.
Если вы хотите сохранить изменения в файле, но прямо сейчас их нужно отменить, то есть способы получше, такие как ветвление и припрятывание – мы рассмотрим их в главе «Ветвление в Git».
Помните, всё, что попало в коммит, почти всегда Git может восстановить. Можно восстановить даже коммиты из веток, которые были удалены, или коммиты, перезаписанные параметром --amend (смотрите «Восстановление данных»). Но всё, что не было включено в коммит и потеряно, – скорее всего потеряно навсегда.
Заключение
Надеюсь, вы разобрались с командой reset и можете её спокойно использовать. Но, возможно, вы всё ещё немного путаетесь, чем именно она отличается от checkout , и не запомнили всех правил, используемых в различных вариантах вызова.
Ниже приведена памятка того, как эти команды воздействуют на каждое из деревьев. В столбце «HEAD» указывается «REF» если эта команда перемещает ссылку (ветку), на которую HEAD указывает, и «HEAD» если перемещается только сам HEAD. Обратите особое внимание на столбец «Сохранность РК?» — если в нем указано NO, то хорошенько подумайте прежде чем выполнить эту команду.
У меня есть локальный репозиторий моего проекта. Там есть несколько коммитов. Последний коммит был сделан необдуманно (вспомнилось, что там есть пара проблем, которые не хотелось бы увековечивать). Я умею возвращаться к предыдущему коммиту (команда Revert). Но это не то, что мне нужно. Так я потеряю много полезного, сделанного между предыдущим коммитом и последним(необдуманным).
В общем, хочу сделать так, чтобы последнего коммита не было, но все мои файлы были такими, какие они есть сейчас.
Слияние коммитов
Давайте посмотрим, как, используя вышеизложенное, сделать кое-что интересное — слияние коммитов.
Предположим, у вас есть проект, в котором первый коммит содержит один файл, второй коммит добавляет новый файл и изменяет первый, а третий коммит снова изменяет первый файл. Второй коммит был сделан в процессе работы и вы хотите слить его со следующим.
Вы можете выполнить git reset --soft HEAD~2 , чтобы вернуть ветку HEAD на какой-то из предыдущих коммитов (на первый коммит, который вы хотите оставить):
Затем просто снова выполните git commit :
Теперь вы можете видеть, что ваша «достижимая» история (история, которую вы впоследствии отправите на сервер), сейчас выглядит так — у вас есть первый коммит с файлом file-a.txt версии v1, и второй, который изменяет файл file-a.txt до версии v3 и добавляет file-b.txt . Коммита, который содержал файл версии v2 не осталось в истории.
Отмена индексации файла
Следующие два раздела демонстрируют как работать с индексом и изменениями в рабочем каталоге. Радует, что команда, которой вы определяете состояние этих областей, также подсказывает вам как отменять изменения в них. Например, вы изменили два файла и хотите добавить их в разные коммиты, но случайно выполнили команду git add * и добавили в индекс оба. Как исключить из индекса один из них? Команда git status напомнит вам:
Прямо под текстом «Changes to be committed» говорится: используйте git reset HEAD … для исключения из индекса. Давайте последуем этому совету и отменим индексирование файла CONTRIBUTING.md :
Команда выглядит несколько странно, но — работает! Файл CONTRIBUTING.md изменен, но больше не добавлен в индекс.
Команда git reset может быть опасной если вызвать её с параметром --hard . В приведенном примере файл не был затронут, следовательно команда относительно безопасна.
На текущий момент этот магический вызов — всё, что вам нужно знать о команде git reset . Мы рассмотрим в деталях что именно делает reset и как с её помощью делать действительно интересные вещи в разделе Раскрытие тайн reset главы 7.
Отмена изменений в файле
Что делать, если вы поняли, что не хотите сохранять свои изменения файла CONTRIBUTING.md ? Как можно просто отменить изменения в нём — вернуть к тому состоянию, которое было в последнем коммите (или к начальному после клонирования, или еще как-то полученному)? Нам повезло, что git status подсказывает и это тоже.
В выводе команды из последнего примера список изменений выглядит примерно так:
Здесь явно сказано как отменить существующие изменения. Давайте так и сделаем:
Как видите, откат изменений выполнен.
Важно понимать, что git checkout -- — опасная команда. Все локальные изменения в файле пропадут — Git просто заменит его версией из последнего коммита. Ни в коем случае не используйте эту команду, если вы не уверены, что изменения в файле вам не нужны.
Если вы хотите сохранить изменения в файле, но прямо сейчас их нужно отменить, то есть способы получше, такие как ветвление и припрятывание — мы рассмотрим их в главе Ветвление в Git.
Помните, все что попало в коммит почти всегда Git может восстановить. Можно восстановить даже коммиты из веток, которые были удалены, или коммиты, перезаписанные параметром --amend (см. Восстановление данных). Но всё, что не было включено в коммит и потеряно — скорее всего, потеряно навсегда.
OPTIONS
Be quiet, only report errors.
Refresh the index after a mixed reset. Enabled by default.
Pathspec is passed in instead of commandline args. If is exactly - then standard input is used. Pathspec elements are separated by LF or CR/LF. Pathspec elements can be quoted as explained for the configuration variable core.quotePath (see git-config[1]). See also --pathspec-file-nul and global --literal-pathspecs .
Only meaningful with --pathspec-from-file . Pathspec elements are separated with NUL character and all other characters are taken literally (including newlines and quotes).
Do not interpret any more arguments as options.
Limits the paths affected by the operation.
For more details, see the pathspec entry in gitglossary[7].
Отмена индексации файла с помощью git restore
В следующих двух разделах показано, как работать с индексом и изменениями рабочей копии с помощью git restore . Приятно то, что команда, которую вы используете для определения состояния этих двух областей, также напоминает вам, как отменить изменения в них. Например, предположим, что вы изменили два файла и хотите зафиксировать их как два отдельных изменения, но случайно набираете git add * и индексируете их оба. Как вы можете убрать из индекса один из них? Команда git status напоминает вам:
Прямо под текстом « Changes to be committed », написано использовать git restore --staged … для отмены индексации файла. Итак, давайте воспользуемся этим советом, чтобы убрать из индекса файл CONTRIBUTING.md :
Файл CONTRIBUTING.md изменен, но снова не индексирован.
Отмена действий с помощью 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 … для отмены индексации файла. Итак, давайте воспользуемся этим советом, чтобы убрать из индекса файл CONTRIBUTING.md :
Файл CONTRIBUTING.md изменен, но снова не индексирован.
Откат измененного файла с помощью git restore
Что, если вы поймете, что не хотите сохранять изменения в файле CONTRIBUTING.md ? Как легко его откатить — вернуть обратно к тому, как он выглядел при последнем коммите (или изначально клонирован, или каким-либо образом помещён в рабочий каталог)? К счастью, git status тоже говорит, как это сделать. В выводе последнего примера, неиндексированная область выглядит следующим образом:
Он довольно недвусмысленно говорит, как отменить сделанные вами изменения. Давайте сделаем то, что написано:
Важно понимать, что git restore — опасная команда. Любые локальные изменения, внесенные в этот файл, исчезнут — Git просто заменит файл последней зафиксированной версией. Никогда не используйте эту команду, если точно не знаете, нужны ли вам эти несохраненные локальные изменения.
In the first three forms, copy entries from to the index. In the last form, set the current branch head ( HEAD ) to , optionally modifying index and working tree to match. The / defaults to HEAD in all forms.
These forms reset the index entries for all paths that match the to their state at . (It does not affect the working tree or the current branch.)
This means that git reset is the opposite of git add . This command is equivalent to git restore [--source=] --staged . .
After running git reset to update the index entry, you can use git-restore[1] to check the contents out of the index to the working tree. Alternatively, using git-restore[1] and specifying a commit with --source , you can copy the contents of a path out of a commit to the index and to the working tree in one go.
Interactively select hunks in the difference between the index and (defaults to HEAD ). The chosen hunks are applied in reverse to the index.
This means that git reset -p is the opposite of git add -p , i.e. you can use it to selectively reset hunks. See the “Interactive Mode” section of git-add[1] to learn how to operate the --patch mode.
This form resets the current branch head to and possibly updates the index (resetting it to the tree of ) and the working tree depending on . If is omitted, defaults to --mixed . The must be one of the following:
Does not touch the index file or the working tree at all (but resets the head to , just like all modes do). This leaves all your changed files "Changes to be committed", as git status would put it.
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.
If -N is specified, removed paths are marked as intent-to-add (see git-add[1]).
Resets the index and working tree. Any changes to tracked files in the working tree since are discarded. Any untracked files or directories in the way of writing any tracked files are simply deleted.
Resets the index and updates the files in the working tree that are different between and HEAD , but keeps those which are different between the index and working tree (i.e. which have changes which have not been added). If a file that is different between and the index has unstaged changes, reset is aborted.
In other words, --merge does something like a git read-tree -u -m , but carries forward unmerged index entries.
Resets index entries and updates files in the working tree that are different between and HEAD . If a file that is different between and HEAD has local changes, reset is aborted.
When the working tree is updated, using --recurse-submodules will also recursively reset the working tree of all active submodules according to the commit recorded in the superproject, also setting the submodules' HEAD to be detached at that commit.
See "Reset, restore and revert" in git[1] for the differences between the three commands.
Читайте также: