Доходчивое объяснение Git Reset
Перевод статьи «Git Reset Explained – How to Save the Day with the Reset Command».
«Помогите! Я закоммитил не в ту ветку!» «Ну вот, опять… Где мой коммит?» Знакомые ситуации, правда?
Я такое слышал неоднократно. Кто-то окликает меня по имени и просит помочь, когда у него что-то пошло не так с git. И такое происходило не только когда я учил студентов, но также и в работе с опытными разработчиками.
Со временем я стал кем-то вроде «того парня, который разбирается в Git».
Мы используем git постоянно, и обычно он помогает нам в работе. Но порой (и куда чаще, чем нам хотелось бы!) что-то идет не так.
Бывает, мы отправляем коммит не в ту ветку. Бывает, теряем часть написанного кода. А можем и добавить в коммит что-то лишнее.
По git есть много онлайн-ресурсов, и часть из них (например, вот эта статья) фокусируется на том, что делать в таких вот нежелательных ситуациях.
Но мне всегда казалось, что в этих ресурсах не хватает объяснений, почему нужно делать так, а не иначе. Когда приводится набор команд, что делает каждая из них? И вообще, как вы пришли к этим командам?
В прошлом посте я рассказывал о внутреннем устройстве Git. И хотя понимать его полезно, читая теория практически всегда недостаточна. Как применить свои знания внутреннего устройства git и использовать их для решения возникающих проблем?
Исходные условия — рабочая директория, индекс и репозиторий
Если вы хорошо ориентируетесь в этой теме, переходите к следующему разделу. Если же вам нужно более глубокое пояснение, почитайте мой предыдущий пост.
После того как мы внесли какие-то изменения, мы хотим отправить их в репозиторий. Репозиторий это набор коммитов, каждый из которых представляет собой архив того, как выглядело рабочее дерево проекта на момент создания этого архива (на нашей машине или на чьей-то еще).
Давайте создадим в рабочей директории какой-нибудь файл и запустим команду git status :
Да, git не записал (не закоммитил) изменения, сделанные в рабочей директории, напрямую в репозиторий.
Вместо этого изменения сначала регистрируются в индексе (или в стейджинге). Оба эти термина означают одно и то же, и оба часто используются в документации git. В этой статье мы тоже будем пользоваться обоими, так как они полностью взаимозаменяемы.
Рабочая директория находится в точно таком же состоянии, как индекс и репозиторий.
При выполнении git commit текущая ветка master начинает указывать на только что созданный объект commit.
Внутренняя работа git reset
Мне нравится представлять git reset как команду, которая поворачивает вспять описанный выше процесс (внесение изменений в рабочей директории, добавление их в индекс, а затем сохранение в репозиторий).
Стадия 1. Обновление HEAD — git reset —soft
Если вернуться к нашему примеру, HEAD будет указывать на commit 2, и таким образом new_file.txt не будет частью дерева текущего коммита. Но он будет частью индекса и рабочей директории.
Стадия 2. Обновление индекса — git reset —mixed
В нашем примере это значит, что индекс будет в том же виде, что и commit 2:
Стадия 3. Обновление рабочей директории — git reset —hard
1, а также обновления индекса до (уже обновленного) HEAD, git пойдет еще дальше и обновит рабочую директорию до состояния индекса.
Применительно к нашему примеру это означает, что рабочая директория будет приведена к состоянию индекса, который уже приведен в состояние commit 2:
Собственно, мы вернули весь процесс на этап до создания файла my_file.txt.
Применяем наши знания в реальных сценариях
1. Упс! Я закоммитил что-то по ошибке
Рассмотрим следующий сценарий. Мы создали файл со строкой «This is very importnt», отправили его в стейджинг, а после — в коммит.
А затем — ой! — обнаружили, что в предложении у нас опечатка.
2. Упс! Я сделал коммит не в ту ветку, а эти изменения мне нужны в новой ветке
Со всеми нами такое случалось. Сделал что-то, закоммитил…
О нет, мы сделали коммит в ветку master, а надо было создать новую и затем сделать пул-реквест.
Я считаю, что здесь будет полезно визуализировать наше положение и то положение, в котором мы хотели бы оказаться.
Собственно, от желаемого состояния нас отделяют три изменения.
Мы можем достичь желаемого положения в три шага:
Во-вторых, нужно сделать так, чтобы master указывала на предыдущий коммит (иными словами, на HEAD
3. Упс! Я отправил коммит не в ту ветку, а он мне нужен в другой (уже существующей) ветке
В этом случае мы проходим те же шаги, что и в предыдущем сценарии. Мы проделали какую-то работу и закоммитили изменения…
Давайте снова изобразим текущее и желаемое положение:
У нас опять же есть три отличия.
Теперь наше положение следующее:
Все, что нам нужно, это сделать так, чтобы master указывала на предыдущий коммит, а не на самый последний. Для этого:
1 — теперь мы вернулись к изначальному состоянию этой ветки.
Таким образом мы достигли желаемого положения:
Итоги
Также мы применили свои новые знания для решения жизненных задач.
Понимание работы git позволяет уверенно действовать в любых ситуациях, а также наслаждаться красотой этого инструмента.
git reset
Git reset и три дерева Git
Начнем работу с создания нового репозитория с помощью приведенных ниже команд.
Рабочий каталог
Первое дерево, которое мы рассмотрим, — рабочий каталог. Это дерево синхронизировано с локальной файловой системой и отображает непосредственные изменения, внесенные в содержимое файлов и каталогов.
Раздел проиндексированных файлов
Далее мы добавим измененный файл reset_lifecycle_file в раздел проиндексированных файлов.
История коммитов
Последнее дерево — история коммитов. Команда git commit добавляет изменения в постоянный снимок, который находится в истории коммитов. Этот снимок также включает состояние раздела проиндексированных файлов на момент выполнения коммита.
Порядок действий
git checkout b
git reset b
Основные параметры
.svg)
Чтобы продемонстрировать это, продолжим работать в репозитории, созданном ранее для примера с тремя деревьями. Сначала внесем в репозиторий некоторые изменения. Выполните в нем следующие команды:
Прежде чем двигаться дальше, изучим состояние раздела проиндексированных файлов:
—mixed
Это режим работы по умолчанию. Указатели ссылок обновляются. Раздел проиндексированных файлов сбрасывается до состояния указанного коммита. Любые изменения, которые были отменены в разделе проиндексированных файлов, перемещаются в рабочий каталог. Давайте продолжим.
Теперь давайте мягко сбросим текущее состояние репозитория.
Прежде чем вернуться назад во времени, проверим текущее состояние репозитория.
Чтобы выяснить, что произошло при этом сбросе, выполним команду git log:
Разница между командами git reset и git revert
Команда revert предназначена для безопасной отмены публичных коммитов, а git reset — для отмены локальных изменений в разделе проиндексированных файлов и рабочем каталоге. Поскольку они предназначены для разных целей, их реализация также различается: команда reset полностью удаляет набор изменений, тогда как команда revert оставляет исходный набор изменений и использует новый коммит для применения отмены.
Не используйте reset в публичной истории
При удалении коммита, после которого другие участники команды начали работу, могут возникнуть серьезные проблемы. Когда коллеги попытаются синхронизироваться с вашим репозиторием, часть истории проекта будет просто отсутствовать. На следующей схеме показано, что происходит при использовании команды reset для публичного коммита. Ветка origin/main является версией вашей локальной главной ветки main в центральном репозитории.
Примеры
Удаляет указанный файл из раздела проиндексированных файлов, но оставляет рабочий каталог без изменений. Эта команда удаляет из индекса подготовленный файл, не перезаписывая все изменения.
Сбрасывает раздел проиндексированных файлов до состояния последнего коммита, но оставляет рабочий каталог без изменений. Эта команда удаляет из индекса все подготовленные файлы, не перезаписывая все изменения, что позволяет повторно собрать снимок состояния с нуля.
Перемещает указатель текущей ветки на более ранний и сбрасывает как раздел проиндексированных файлов, так и рабочий каталог до состояния этого коммита. Эта команда уничтожит не только неотправленные изменения, но и все коммиты, которые были добавлены после указанного коммита.
Удаление файла из раздела проиндексированных файлов
Как видите, команда git reset помогает соблюдать согласованность коммитов, позволяя не вносить изменения, которые не связаны со следующим коммитом.
Удаление локальных коммитов
В следующем примере показан более продвинутый сценарий использования. Он демонстрирует, что происходит, когда вы некоторое время работали над новой экспериментальной функцией, но после добавления нескольких коммитов состояния решили полностью все удалить.
Команда git reset HEAD
2 перемещает указатель текущей ветки на два коммита назад, по сути удаляя из истории проекта оба снимка состояния, которые мы только что создали. Помните, что этот вид команды reset можно использовать только для неопубликованных коммитов. Никогда не выполняйте эту операцию, если вы уже отправили свои коммиты в общий репозиторий.
Резюме
Готовы изучить git reset?
Ознакомьтесь с этим интерактивным обучающим руководством.
Как использовать git reset
Главное меню » Linux » Как использовать git reset
Параметры сброса Git:
| Вариант | Цель |
|---|---|
| -soft | Он используется для запуска команды сброса без перезаписи каких-либо незафиксированных измененных файлов. Он не сбрасывает индекс и не вносит изменений в текущее рабочее дерево. |
| –mixed | Это параметр сброса по умолчанию, он сбрасывает индекс, но не вносит никаких изменений в рабочее дерево. |
| -hard | Он сбрасывает и индекс, и рабочее дерево. Таким образом, любые зафиксированные или незафиксированные изменения, сделанные в рабочем дереве, будут потеряны. |
| –merge | Он сбрасывает индекс и изменяет файлы в рабочем дереве, если существует какое-либо различие между индексом и рабочим деревом. Если в рабочем каталоге существует какой-либо файл, который не спрятан, сброс будет прерван. |
| -keep | Он сбрасывает записи индекса и изменяет файлы рабочего дерева при любых различиях между индексом и рабочим деревом. Если разница существует в локальном файле, сброс будет отменен. |
| -[no-]recurse-submodules | Он используется для рекурсивного сброса рабочего дерева всех активных подмодулей. |
Предпосылки:
Установка GitHub Desktop
GitHub Desktop помогает пользователю git графически выполнять задачи, связанные с git. Вы можете легко загрузить последнюю версию этого приложения для Ubuntu с github.com. Вы должны установить и настроить это приложение после загрузки, чтобы использовать его. Вы также можете проверить руководство по установке GitHub Desktop в Ubuntu, чтобы правильно узнать процесс установки.
Создание локального репозитория
Вы должны создать локальный репозиторий для тестирования команд, используемых в этой статье для проверки и разрешения конфликта слияния.
Сброс Git для конкретного файла:
В этой части статьи показано использование команды `git reset` для конкретного файла. Выполните следующую команду, чтобы проверить текущий статус репозитория, добавить файл send-email3.php и сбросить файл send-email3.php.
Следующие выходные данные показывают, что команда сброса изменила отслеживаемый файл на неотслеживаемый файл без какой-либо опции. Чтобы изменить статус всех отслеживаемых файлов репозитория на неотслеживаемые файлы, вы должны использовать команду git reset HEAD.
Использование команды `git reset` с – вариантом soft показано в этой части статьи. Эта опция сохраняет рабочее дерево неизменным. Выполните следующую команду, чтобы проверить текущий статус репозитория, добавить файл send-email3.php и сбросить репозиторий с параметром –soft.
Следующий вывод появится после выполнения вышеуказанных команд. Выходные данные показывают, что рабочий тройник остался неизменным после выполнения команды reset, поскольку опция –soft сбрасывает только индекс.
В этой части статьи показано использование команды `git reset` с параметром –hard. Эта опция перемещает указатель HEAD и обновляет содержимое рабочего дерева с содержимым, на которое указывает HEAD. Выполните следующую команду, чтобы проверить текущий статус репозитория, добавить файл send-email3.php и сбросить репозиторий с параметром –hard.
Следующий вывод появится после выполнения вышеуказанных команд. Выходные данные показывают, что рабочий тройник очищен и нечего фиксировать после выполнения команды сброса, а добавленный файл был удален из репозитория.
Сброс Git с опцией –mixed:
В этой части руководства показано использование команды `git reset` с параметром –mixed. Этот параметр перемещает указатель HEAD и обновляет содержимое промежуточной области содержимым, на которое указывает HEAD. Но он не обновляет рабочий древовидный параметр –hard и предоставляет информацию о неотслеживаемых файлах. Создайте новый файл с именем send-email-new.php в текущей папке репозитория. Выполните следующую команду, чтобы проверить текущий статус репозитория, добавить файл send-email3.php и сбросить репозиторий с параметром –mixed.
Следующий вывод появится после выполнения вышеуказанных команд. Выходные данные показывают, что команда сброса сохранила текущий рабочий каталог неизменным, поскольку локальный репозиторий изменился, что задача не была зафиксирована. Итак, задача сброса прервана.
Заключение:
В этой статье были объяснены четыре различных способа запуска команды `git reset` с использованием локального демонстрационного репозитория. Первый сброс был применен к определенному файлу. Второй сброс был применен с опцией –soft. Третий сброс применяется с опцией –hard. Четвертый сброс был применен с опцией –mixed. Мы надеемся, что читатели правильно воспользуются командой `git reset` после прочтения этого руководства.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Раскрытие тайн reset
Три дерева
Разобраться с командами reset и checkout будет проще, если считать, что Git управляет содержимым трёх различных деревьев. Здесь под «деревом» мы понимаем «набор файлов», а не специальную структуру данных. (В некоторых случаях индекс ведет себя не совсем так, как дерево, но для наших текущих целей его проще представлять именно таким.)
В своих обычных операциях Git управляет тремя деревьями:
Снимок последнего коммита, родитель следующего
Снимок следующего намеченного коммита
Указатель HEAD
HEAD — это указатель на текущую ветку, которая, в свою очередь, является указателем на последний коммит, сделанный в этой ветке. Это значит, что HEAD будет родителем следующего созданного коммита. Как правило, самое простое считать HEAD снимком вашего последнего коммита.
На самом деле, довольно легко увидеть, что представляет из себя этот снимок. Ниже приведён пример получения содержимого каталога и контрольных сумм для каждого файла в HEAD:
Команды cat-file и ls-tree являются «служебными» (plumbing) командами, которые используются внутри системы и не требуются при ежедневной работе, но они помогают нам разобраться, что же происходит на самом деле.
Индекс
Git заполняет индекс списком изначального содержимого всех файлов, выгруженных в последний раз в ваш рабочий каталог. Затем вы заменяете некоторые из таких файлов их новыми версиями и команда git commit преобразует изменения в дерево для нового коммита.
Технически, индекс не является древовидной структурой, на самом деле, он реализован как сжатый список (flattened manifest) — но для наших целей такого представления будет достаточно.
Рабочий Каталог
Технологический процесс
Основное предназначение Git — это сохранение снимков последовательно улучшающихся состояний вашего проекта, путём управления этими тремя деревьями.
На данном этапе только дерево Рабочего Каталога содержит данные.
Теперь мы хотим закоммитить этот файл, поэтому мы используем git add для копирования содержимого Рабочего Каталога в Индекс.
Теперь мы хотим внести изменения в файл и закоммитить его. Мы пройдём через всё ту же процедуру; сначала мы отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла v2 и обозначать красным цветом.
Сейчас команда git status не показывает ничего, так как снова все три дерева одинаковые.
Переключение веток и клонирование проходят через похожий процесс. Когда вы переключаетесь (checkout) на ветку, HEAD начинает также указывать на новую ветку, ваш Индекс замещается снимком коммита этой ветки, и затем содержимое Индекса копируется в ваш Рабочий Каталог.
Назначение команды reset
Команда reset становится более понятной, если рассмотреть её с учётом вышеизложенного.
В следующих примерах предположим, что мы снова изменили файл file.txt и закоммитили его в третий раз. Так что наша история теперь выглядит так:
Шаг 1: Перемещение указателя HEAD
Шаг 2: Обновление Индекса (—mixed)
), выполнение команды также остановится на этом шаге.
Шаг 3: Обновление Рабочего Каталога (—hard)
Резюме
Команда reset в заранее определённом порядке перезаписывает три дерева Git, останавливаясь тогда, когда вы ей скажете:
Делает Рабочий Каталог таким же как и Индекс.
Reset с указанием пути
Перемещает ветку, на которую указывает HEAD (будет пропущено)
Делает Индекс таким же как и HEAD (остановится здесь)
То есть, фактически, она копирует файл file.txt из HEAD в Индекс.
Именно поэтому в выводе git status предлагается использовать такую команду для отмены индексации файла. (Смотрите подробности в Отмена индексации файла.)
Слияние коммитов
Давайте посмотрим, как, используя вышеизложенное, сделать кое-что интересное — слияние коммитов.
Предположим, у вас есть проект, в котором первый коммит содержит один файл, второй коммит добавляет новый файл и изменяет первый, а третий коммит снова изменяет первый файл. Второй коммит был сделан в процессе работы и вы хотите слить его со следующим.
Затем просто снова выполните git commit :
Сравнение с checkout
Без указания пути
Второе важное отличие заключается в том, как эти команды обновляют HEAD. В то время как reset перемещает ветку, на которую указывает HEAD, команда checkout перемещает сам HEAD так, чтобы он указывал на другую ветку.
Итак, в обоих случаях мы перемещаем HEAD на коммит A, но важное отличие состоит в том, как мы это делаем. Команда reset переместит также и ветку, на которую указывает HEAD, а checkout перемещает только сам HEAD.
С указанием пути
Заключение
Ниже приведена памятка того, как эти команды воздействуют на каждое из деревьев. В столбце «HEAD» указывается «REF» если эта команда перемещает ссылку (ветку), на которую HEAD указывает, и «HEAD» если перемещается только сам HEAD. Обратите особое внимание на столбец «Сохранность РК?» — если в нем указано NO, то хорошенько подумайте прежде чем выполнить эту команду.
Сравнение 5 команд Git: revert, checkout, reset, merge и rebase
revert, checkout, reset
git revert
Команда git revert – безопасный способ отменить операцию без потери истории коммитов. Команда отменяет действия прошлых коммитов, создавая новый, содержащий все отменённые изменения. Эта команда полезна, когда вы уже запушили изменения в удаленный репозиторий, так как она сохраняет нетронутым исходный коммит.
Откатиться с помощью commit-хэшей:
Можно и с помощью диапазонов :
Действие git revert
git checkout
Универсальный инструмент git checkout позволяет переключаться между ветками, проверять старые коммиты и отменять локальные незакоммиченные изменения, переключая HEAD и изменяя рабочий каталог.
Для переключения между ветками:
Для проверки более старого коммита с помощью хэша:
Чтобы проверить более старый коммит, используя диапазоны:
Чтобы отменить все локальные незакоммиченные изменения:
Чтобы отменить определенное локальное незакоммиченное изменение:
Действие git checkout
git reset
Команда git reset – это мощный способ отменить операцию. Существует три возможных аргумента:
Действие git reset
merge vs rebase
Когда над проектом работает несколько человек, в какой-то момент нужно объединить код. Команды rebase и merge имеют разные подходы для консолидации изменений из одной ветви в другую.
Сравнение merge и rebase
git merge
Чтобы объединить последние изменения из master в вашу ветку:
git rebase
Команда git rebase перемещает историю всей ветки поверх другой, переписывая историю проекта новыми коммитами.
Команда полезна, если вы предпочитаете чистую и линейную историю проекта. Однако перестроить изменения, перенесенные в главную ветку удаленного репозитория небезопасно, т. к. вы будете изменять историю главной ветви, в то время как члены вашей команды будут продолжать работать над ней.
