Как отменить git reset hard
Прежде всего надо понять что такое гит и что делает git reset —hard . Гит это набор ссылок, где каждая хранит изменения файлов. Команда git reset перемещает указатель на выбранную ссылку, а флаг —hard еще и обновляет все файлы в соотвествии с ссылкой. Отсюда решение на первый взгляд парадоксальное — чтобы отменить git reset —hard нужно сделать git reset —hard на отмененную ссылку.
echo 'foobaz' > 1.txt git add . git commit -m 'add 1.txt' # [main (root-commit) dd64acb] add 1.txt # 1 file changed, 1 insertion(+) # create mode 100644 1.txt echo 'hellowordl' > 2.txt git add . git commit -m 'add 2.txt' # [main c626c6c] add 2.txt # 1 file changed, 1 insertion(+) # create mode 100644 2.txt git log # c626c6c (HEAD -> main) add 2.txt # dd64acb add 1.txt git reset --hard HEAD^1 # HEAD is now at dd64acb add 1.txt cat 2.txt # cat: 2.txt: No such file or directory # команда git reflog позволяет посмотреть всю историю коммитов и найти хеш нужного нам коммита git reflog # dd64acb HEAD@: reset: moving to HEAD^1 # c626c6c (HEAD -> main) HEAD@: commit: add 2.txt # dd64acb HEAD@: commit (initial): add 1.txt git reset --hard c626c6c # HEAD is now at c626c6c add 2.txt cat 2.txt # hellowordl 7.7 Инструменты Git — Раскрытие тайн reset
Перед тем, как перейти к более специализированными утилитам, давайте поговорим о reset и checkout . Эти команды кажутся самыми непонятными из всех, которые есть в Git, когда вы в первый раз сталкиваетесь с ними. Они делают так много, что попытки по-настоящему их понять и правильно использовать кажутся безнадёжными. Для того, чтобы всё же достичь этого, мы советуем воспользоваться простой аналогией.
Три дерева
Разобраться с командами reset и checkout будет проще, если считать, что Git управляет содержимым трёх различных деревьев. Здесь под «деревом» мы понимаем «набор файлов», а не специальную структуру данных. (В некоторых случаях индекс ведет себя не совсем так, как дерево, но для наших текущих целей его проще представлять именно таким.)
В своих обычных операциях Git управляет тремя деревьями:
Снимок последнего коммита, родитель следующего
Снимок следующего намеченного коммита
Указатель HEAD
HEAD — это указатель на текущую ветку, которая, в свою очередь, является указателем на последний коммит, сделанный в этой ветке. Это значит, что HEAD будет родителем следующего созданного коммита. Как правило, самое простое считать HEAD снимком вашего последнего коммита.
На самом деле, довольно легко увидеть, что представляет из себя этот снимок. Ниже приведён пример получения содержимого каталога и контрольных сумм для каждого файла в HEAD:
$ git cat-file -p HEAD tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf author Scott Chacon 1301511835 -0700 committer Scott Chacon 1301511835 -0700 initial commit $ git ls-tree -r HEAD 100644 blob a906cb2a4a904a152. README 100644 blob 8f94139338f9404f2. Rakefile 040000 tree 99f1a6d12cb4b6f19. libКоманды cat-file и ls-tree являются «служебными» (plumbing) командами, которые используются внутри системы и не требуются при ежедневной работе, но они помогают нам разобраться, что же происходит на самом деле.
Индекс
Индекс — это ваш следующий намеченный коммит. Мы также упоминали это понятие как «область подготовленных изменений» Git — то, что Git просматривает, когда вы выполняете git commit .
Git заполняет индекс списком изначального содержимого всех файлов, выгруженных в последний раз в ваш рабочий каталог. Затем вы заменяете некоторые из таких файлов их новыми версиями и команда git commit преобразует изменения в дерево для нового коммита.
$ git ls-files -s 100644 a906cb2a4a904a152e80877d4088654daad0c859 0 README 100644 8f94139338f9404f26296befa88755fc2598c289 0 Rakefile 100644 47c6340d6459e05787f644c2447d2595f5d3a54b 0 lib/simplegit.rbПовторим, здесь мы используем служебную команду ls-files , которая показывает вам, как выглядит сейчас ваш индекс.
Технически, индекс не является древовидной структурой, на самом деле, он реализован как сжатый список (flattened manifest) — но для наших целей такого представления будет достаточно.
Рабочий Каталог
Наконец, у вас есть рабочий каталог. Два других дерева сохраняют свое содержимое эффективным, но неудобным способом внутри каталога .git . Рабочий Каталог распаковывает их в настоящие файлы, что упрощает для вас их редактирование. Считайте Рабочий Каталог песочницей, где вы можете опробовать изменения перед их коммитом в индекс (область подготовленных изменений) и затем в историю.
$ tree . ├── README ├── Rakefile └── lib └── simplegit.rb 1 directory, 3 filesТехнологический процесс
Основное предназначение 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 начинает также указывать на новую ветку, ваш Индекс замещается снимком коммита этой ветки, и затем содержимое Индекса копируется в ваш Рабочий Каталог.
Назначение команды 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 )
- Делает Рабочий Каталог таким же как и Индекс.
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 для отмены индексации части содержимого. Таким способом вы можете избирательно отменять индексацию или откатывать изменения.
Слияние коммитов
Давайте посмотрим, как, используя вышеизложенное, сделать кое-что интересное — слияние коммитов.
Допустим, у вас есть последовательность коммитов с сообщениями вида «упс.», «В работе» и «позабыл этот файл». Вы можете использовать reset для того, чтобы просто и быстро слить их в один. (В разделе Объединение коммитов главы 7 представлен другой способ сделать то же самое, но в данном примере проще воспользоваться reset .)
Предположим, у вас есть проект, в котором первый коммит содержит один файл, второй коммит добавляет новый файл и изменяет первый, а третий коммит снова изменяет первый файл. Второй коммит был сделан в процессе работы и вы хотите слить его со следующим.
Вы можете выполнить git reset —soft HEAD~2 , чтобы вернуть ветку HEAD на какой-то из предыдущих коммитов (на первый коммит, который вы хотите оставить):
Затем просто снова выполните git commit :
Теперь вы можете видеть, что ваша «достижимая» история (история, которую вы впоследствии отправите на сервер), сейчас выглядит так — у вас есть первый коммит с файлом file-a.txt версии v1, и второй, который изменяет файл file-a.txt до версии v3 и добавляет file-b.txt . Коммита, который содержал файл версии v2 не осталось в истории.
Сравнение с 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 , и не запомнили всех правил, используемых в различных вариантах вызова.
Ниже приведена памятка того, как эти команды воздействуют на каждое из деревьев. В столбце «HEAD» указывается «REF» если эта команда перемещает ссылку (ветку), на которую HEAD указывает, и «HEAD» если перемещается только сам HEAD. Обратите особое внимание на столбец «Сохранность рабочего каталога?» — если в нём указано НЕТ, то хорошенько подумайте прежде чем выполнить эту команду.
На уровне коммитов
Когда что-то пошло не так: git reset
В этой статье мы рассмотрим команду git reset , которая позволит отменить неправильные/неудачные изменения, сделанные локально, а также «откатить» неудачный merge (слияние).
Детям из Мариуполя нужно 120 ноутбуков для обучения — подари старое «железо», пусть оно работает на будущее Украины
Постановка задачи
Допустим, вы работаете над проектом, и сделали изменения, которые теперь хотите отменить. Можно выполнить git status и увидеть все сделанные изменения, после чего вручную отменить ненужные. Но что если изменений очень много (такое случается после неудачных «ручных» мерджей)? В таком случае вам поможет команда git reset . Эта команда подобна скальпелю — она очень острая/эффективная, и именно поэтому ее следует использовать с осторожностью.
Далее рассмотрим основные сценарии ее использования.
Курс Python basic.
Після курсу ви зможете впевнено працювати з чатботами, скриптами, вбудованими системами, веб- та мобільними застосунками, а також навіть ігровими програмами.
Основные сведения
Вообще говоря, назначение git reset — взять текущую ветку и «сбросить» (переназначить, англ. reset ) ее так, чтобы она указывала на какой-либо другой коммит; в частности, засинхронизировать индекс и рабочее дерево репозитория. Более конкретно, если ваша ветка master (в настоящее время в статусе checkout ) выглядит так:
— A — B — C (HEAD, master)
где A, B, C — последовательные коммиты ветки master . И вы хотите, чтобы master заканчивалась коммитом B, а не С, то вы используете git reset (в данном случае — это хэш коммита B), чтобы переместить ее туда:
— A — B (HEAD, master) # — коммит C все еще здесь, но никакая ветка больше не указывает на этот коммит
Важный момент: это поведение существенно отличается от команды git checkout , которая привела бы к такому результату:
— A — B (HEAD) — C (master)
В результате вы получите состояние с отсоединенным (detached) указателем HEAD . Итак, HEAD , ваше рабочее дерево, индекс — все соответствуют коммиту B, но ветка master была оставлена на коммите C. Если в данном состоянии репозитория вы сделаете новый коммит D, вы получите такую конфигурацию, которая, скорее всего, отличается от того, чего вы хотели достичь:
Запомните главное: reset не делает коммитов, он всего лишь меняет ветку (которая указывает на коммит), чтобы она указывала на другой коммит. Другими словами, что бы ни значило само слово reset , логически оно определяет, что происходит с вашим индексом и рабочим деревом.
Курс Стратегический маркетинг.
Від хаосу до системного маркетингу разом із Тетяною Лукинюк, B2C-директором у Kyivstar, колишнім CMO у Coca-Cola, Mars Ukraine та генеральною директоркою у Red Bull Ukraine.
Примеры использования
Рассмотрим некоторые основные варианты использования git reset .
Команду можно использовать для самых разных целей; общая идея состоит в том, что все они включают сброс ветки, индекса и/или рабочего дерева с тем, чтобы они указывали/соответствовали заданному коммиту.
Будьте внимательны
- Ключ –hard действительно может привести к потере результатов работы. Он модифицирует рабочее дерево репозитория.
- git reset [options] может привести (если опустить технические детали) к потере коммитов. В условном примере, приведенном выше, мы потеряли коммит C. Он по-прежнему находится в репозитории, и вы можете найти его командами git reflog show HEAD или git reflog show master, но на самом деле к нему нельзя получить доступ из какой-либо ветки.
Аргументы
Если сократить документацию git reset до одного абзаца, наиболее частый путь использования команды — git reset [] [пути. ] , что сбросит данные пути до их состояния из данного коммита. Если пути не указаны, все дерево будет сброшено («ресетнуто»), а если коммит не указан, подразумевается коммит HEAD (текущий коммит).
Это стандартный паттерн команд git (включая checkout , diff , log , хотя семантика может несколько отличаться), так что сюрпризов здесь не предвидится.
Например, git reset сбрасывает все в пути к его состоянию в ветке ; git reset — сбрасывает текущую директорию к ее состоянию в HEAD , а простой git reset сбрасывает все дерево к его состоянию в HEAD .
Основные опции для работы с деревом и индексом
Всего есть четыре опции для управления тем, что происходит с вашим рабочим деревом и индексом во время исполнения команды reset .
Напомним, «индекс» — это «сцена» git’а, условное место, где происходят изменения, когда вы, например, выполняете команду git add , подготавливая свой коммит.
Курс Англійської.
Обери викладача за своїми вимогами серед 1100+ фахівців в Englishdom.
- –hard — заставляет весь контент соответствовать коммиту, к которому вы сбрасываете (ресетите). Наверное, это самый простой для понимания ключ (опция). Все ваши локальные изменения исчезают. Основной случай применения — удалить вашу последнюю работу без переключения коммитов: git reset —hard означает git reset —hard HEAD , то есть, не изменяя ветку, избавиться от всех локальных изменений. Другой случай применения — перенести ветку из одного места в другое и держать при этом индекс/рабочее дерево в синхронизированном состоянии.
Напоминаем, эта опция действительно может привести к потере вашей работы, поскольку она модифицирует ваше рабочее дерево. Будьте на 100% уверены, что действительно хотите отказаться от локальных изменений, перед тем как выполнять reset —hard .
- –mixed — это опция по умолчанию, то есть git reset означает git reset —mixed . Эта команда сбрасывает индекс, но не рабочее дерево. Это означает, что все ваши файлы остаются неизменными, но любые изменения между текущим коммитом и коммитом, к которому вы сбрасываете, будут показаны как локальные изменения (или неотслеживаемые/untracked файлы) во время выполнения команды git status . Используйте эту опцию, когда вы вдруг поняли, что сделали неправильные коммиты, но все же хотите оставить некоторые изменения, которые сделали, чтобы их исправить и закоммитить снова. Чтобы закоммитить, вам придется добавить файлы в индекс снова командой git add .
- —soft не изменяет индекс или рабочее дерево. Все ваши файлы остаются нетронутыми, как если бы вы использовали —mixed , но все изменения показываются как готовые к коммиту во время выполнения git status (то есть, зачекиненные и готовые к коммиту).
Используйте эту опцию, если осознали, что сделали несколько плохих коммитов, но сейчас состояние проекта правильное, и все что вам нужно — перекоммитить его еще раз. Индекс не тронут, поэтому вы можете закоммитить немедленно — результирующий коммит будет иметь то же содержание, которое было до выполнения reset .
- –merge — эта опция добавлена в git относительно недавно, ее предназначение — прервать неудачное (failed) слияние (merge). Это бывает необходимо, потому что git merge в принципе позволяет осуществить попытку слияния с «грязным» рабочим деревом (грязным — в смысле «с локальными изменениями»), если эти изменения содержатся в файлах, не затронутых слиянием.
git reset —merge сбрасывает индекс (подобно опции —mixed — все изменения показываются как локальные изменения) и сбрасывает все файлы, затронутые слиянием, но не трогает остальные файлы. Это может позволить восстановить все до состояния, которое было до «плохого» слияния. Скорее всего, вы будете использовать это как git reset —merge (что означает git reset —merge HEAD ), потому что хотите сбросить только изменения, вызванные попыткой слияния, а не переместить ветку (указатель HEAD не изменился, поскольку слияние было неудачным).
Если говорить более конкретно, представим, что мы поменяли файлы A и B и пытаемся «смерджиться» в ветку с измененными файлами C и D. Слияние «фейлится» по какой-либо причине, и мы решаем прервать его. Используем git reset —merge . Это приводит C и D обратно к состоянию, которое у них было в HEAD , но не затрагивает изменения в A и B, поскольку они не участвовали в попытке слияния.
Странная нотация (~ и ^)
При использовании команды git reset «странная нотация» бывает особенно полезной, поскольку позволяет указывать коммиты, близкие к HEAD , без необходимости написания их хэшей:
- HEAD~ — это сокращенная запись HEAD~1 и означает первого родителя коммита. HEAD~2 означает первого родителя у первого родителя коммита. HEAD~n можно понимать как «n коммитов перед HEAD» или «n-ый предок HEAD» .
- HEAD^ (или HEAD^1 ) тоже означает первого родителя коммита. Но вот HEAD^2 означает второго родителя коммита. Помните, коммит, представляющий собой нормальное слияние (merge), имеет двух родителей: первый родитель — это коммит, в который осуществляется слияние, а второй родитель — коммит, который был слит. Вообще говоря, слияния могут иметь произвольно много родителей (octopus merges).
- Операторы ^ и ~ могут выстраиваться в линию, например, HEAD~3^2 будет означать второго родителя предка HEAD третьего уровня; HEAD^^2 — второго родителя первого родителя HEAD ; HEAD^^^ — это просто эквивалент HEAD~3 .
Заключение
В этой статье мы рассмотрели команду git, которая позволяет отменить/исправить локальные изменения — git reset . Изучили различные условия, в которых приходится вносить исправления: отмена всего, частичная отмена, отмена в случае слияния. Освежили полезную «странную» нотацию для указания коммита без хэша — «~ и ^» нотацию.
Более подробно про нашу тему в этом видео: как различить soft, mixed и hard Git Reset:
Курс Проджект-менеджмент в IT.
Навчайся у найкращих, курс проводить Тарас Федорук, найкращий PM за версією Ukrainian IT Awards у 2019 році.
Доходчивое объяснение Git Reset
Перевод статьи «Git Reset Explained – How to Save the Day with the Reset Command».
«Помогите! Я закоммитил не в ту ветку!» «Ну вот, опять… Где мой коммит?» Знакомые ситуации, правда?
Я такое слышал неоднократно. Кто-то окликает меня по имени и просит помочь, когда у него что-то пошло не так с git. И такое происходило не только когда я учил студентов, но также и в работе с опытными разработчиками.
Со временем я стал кем-то вроде «того парня, который разбирается в Git».
Мы используем git постоянно, и обычно он помогает нам в работе. Но порой (и куда чаще, чем нам хотелось бы!) что-то идет не так.
Бывает, мы отправляем коммит не в ту ветку. Бывает, теряем часть написанного кода. А можем и добавить в коммит что-то лишнее.
По git есть много онлайн-ресурсов, и часть из них (например, вот эта статья) фокусируется на том, что делать в таких вот нежелательных ситуациях.
Но мне всегда казалось, что в этих ресурсах не хватает объяснений, почему нужно делать так, а не иначе. Когда приводится набор команд, что делает каждая из них? И вообще, как вы пришли к этим командам?
В прошлом посте я рассказывал о внутреннем устройстве Git. И хотя понимать его полезно, читая теория практически всегда недостаточна. Как применить свои знания внутреннего устройства git и использовать их для решения возникающих проблем?
В этом посте я хотел бы построить мост между теорией и практикой и рассказать о команде git reset . Мы разберем, что делает эта команда, что происходит за кулисами, а также применим эти знания в различных сценариях.
Исходные условия — рабочая директория, индекс и репозиторий
Чтобы разобраться во внутренних механизмах git reset , важно понимать процесс записи изменений внутри git. В частности, я имею в виду записи в рабочей директории, индексе и репозитории.
Если вы хорошо ориентируетесь в этой теме, переходите к следующему разделу. Если же вам нужно более глубокое пояснение, почитайте мой предыдущий пост.
Когда мы работаем над кодом своего проекта, мы делаем это в рабочей директории. Ею может быть любая директория в нашей файловой системе, имеющая привязанный к ней репозиторий. В ней хранятся папки и файлы нашего проекта, а также директория под названием .git.
После того как мы внесли какие-то изменения, мы хотим отправить их в репозиторий. Репозиторий это набор коммитов, каждый из которых представляет собой архив того, как выглядело рабочее дерево проекта на момент создания этого архива (на нашей машине или на чьей-то еще).
Давайте создадим в рабочей директории какой-нибудь файл и запустим команду git status :
Да, git не записал (не закоммитил) изменения, сделанные в рабочей директории, напрямую в репозиторий.
Вместо этого изменения сначала регистрируются в индексе (или в стейджинге). Оба эти термина означают одно и то же, и оба часто используются в документации git. В этой статье мы тоже будем пользоваться обоими, так как они полностью взаимозаменяемы.
Когда мы применяем git add , мы добавляем файлы (или изменения внутри файлов) в стейджинг. Давайте попробуем использовать эту команду для только что созданного файла:
Как показывает git status , наш файл теперь в стейджинге и готов к коммиту. Да, он еще не является частью никакого коммита. Другими словами, сейчас он находится в рабочей директории, а также в индексе, но не в репозитории.
Если мы теперь выполним git commit , мы создадим коммит на основе состояния индекса. Таким образом новый коммит (в примере — commit 3) будет включать файл, который мы чуть ранее добавили в стейджинг.
Рабочая директория находится в точно таком же состоянии, как индекс и репозиторий.
При выполнении git commit текущая ветка master начинает указывать на только что созданный объект commit.
Внутренняя работа git reset
Мне нравится представлять git reset как команду, которая поворачивает вспять описанный выше процесс (внесение изменений в рабочей директории, добавление их в индекс, а затем сохранение в репозиторий).
У git reset есть три режима: —soft , —mixed и —hard . Я рассматриваю их как три стадии:
- Стадия 1. Обновление HEAD — git reset —soft
- Стадия 2. Обновление индекса — git reset —mixed
- Стадия 3. Обновление рабочей директории — git reset —hard
Стадия 1. Обновление HEAD — git reset —soft
Прежде всего, git reset меняет то, на что указывает HEAD. Если мы выполним git reset —hard HEAD~1 , HEAD будет указывать не на master, а на HEAD~1. Если использовать флаг —soft , git reset на этом и остановится.
Если вернуться к нашему примеру, HEAD будет указывать на commit 2, и таким образом new_file.txt не будет частью дерева текущего коммита. Но он будет частью индекса и рабочей директории.
Если посмотреть git status , мы увидим, что этот файл определенно в стейджинге, но не закоммичен.
Иными словами, мы вернули процесс на стадию, где мы уже применили git add , но еще не применяли git commit .
Стадия 2. Обновление индекса — git reset —mixed
Если мы используем git reset —mixed HEAD~1 , git не остановится на обновлении того, на что указывает HEAD. Помимо этого обновится еще и индекс (до состояния уже обновленного HEAD).
В нашем примере это значит, что индекс будет в том же виде, что и commit 2:
Таким образом мы вернули процесс на стадию до выполнения команды git add . Новосозданный файл является частью рабочей директории, но не индекса и не репозитория.
Стадия 3. Обновление рабочей директории — git reset —hard
Если использовать git reset — hard HEAD~1 , то после перевода указателя HEAD (на что бы он ни указывал раньше) на HEAD~1, а также обновления индекса до (уже обновленного) HEAD, git пойдет еще дальше и обновит рабочую директорию до состояния индекса.
Применительно к нашему примеру это означает, что рабочая директория будет приведена к состоянию индекса, который уже приведен в состояние commit 2:
Собственно, мы вернули весь процесс на этап до создания файла my_file.txt.
Применяем наши знания в реальных сценариях
Теперь, когда мы разобрались с тем, как работает git reset , давайте применим эти знания, чтобы спасти какую-нибудь ситуацию!
1. Упс! Я закоммитил что-то по ошибке
Рассмотрим следующий сценарий. Мы создали файл со строкой «This is very importnt», отправили его в стейджинг, а после — в коммит.
А затем — ой! — обнаружили, что в предложении у нас опечатка.
Ну, теперь-то мы знаем, что это можно легко исправить. Мы можем отменить наш последний коммит и вернуть файл в рабочую директорию, используя git reset —mixed HEAD~1 . Теперь моно отредактировать содержимое файла и сделать коммит еще раз.
Совет. В данном конкретном случае мы также можем использовать git commit —amend , как описано здесь.
2. Упс! Я сделал коммит не в ту ветку, а эти изменения мне нужны в новой ветке
Со всеми нами такое случалось. Сделал что-то, закоммитил…
О нет, мы сделали коммит в ветку master, а надо было создать новую и затем сделать пул-реквест.
Я считаю, что здесь будет полезно визуализировать наше положение и то положение, в котором мы хотели бы оказаться.
Собственно, от желаемого состояния нас отделяют три изменения.
- Ветка new должна указывать на наш недавно добавленный коммит.
- Ветка master должна указывать на предыдущий коммит.
- HEAD должен указывать на new.
Мы можем достичь желаемого положения в три шага:
Во-первых, нужно сделать так, чтобы ветка new указывала на недавно добавленный коммит. Достичь этого можно при помощи команды git branch new . Таким образом мы достигаем следующего состояния:
Во-вторых, нужно сделать так, чтобы master указывала на предыдущий коммит (иными словами, на HEAD~1). Достичь этого можно при помощи команды git reset —hard HEAD~1 . Таким образом мы достигаем следующего состояния:
Наконец, мы хотели бы оказаться в ветке new, т. е. сделать так, чтобы HEAD указывал на new . Это легко достижимо путем выполнения команды git checkout new .
- git branch new
- git reset —hard HEAD~1
- git checkout new
3. Упс! Я отправил коммит не в ту ветку, а он мне нужен в другой (уже существующей) ветке
В этом случае мы проходим те же шаги, что и в предыдущем сценарии. Мы проделали какую-то работу и закоммитили изменения…
О нет, мы отправили коммит в ветку master , а нужно было отправить в совсем другую.
Давайте снова изобразим текущее и желаемое положение:
У нас опять же есть три отличия.
Нам нужно, чтобы самый последний коммит оказался в ветке existing. Поскольку в настоящее время на этот коммит указывает master , мы можем попросить git взять последний коммит из ветки master и применить его к ветке existing :
- git checkout existing — переключение на ветку existing ,
- git cherry-pick master — применение последнего коммита в ветке master к текущей ветке ( existing ).
Теперь наше положение следующее:
Все, что нам нужно, это сделать так, чтобы master указывала на предыдущий коммит, а не на самый последний. Для этого:
- git checkout master — смена активной ветки на master ,
- git reset —hard HEAD~1 — теперь мы вернулись к изначальному состоянию этой ветки.
Таким образом мы достигли желаемого положения:
Итоги
В этой статье мы изучили, как работает git reset , а также разобрали три разных режима этой команды: —soft , —mixed и —hard .
Также мы применили свои новые знания для решения жизненных задач.
Понимание работы git позволяет уверенно действовать в любых ситуациях, а также наслаждаться красотой этого инструмента.