git reset mixed что делает

Раскрытие тайн 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, то хорошенько подумайте прежде чем выполнить эту команду.

Источник

Git reset mixed что делает

Check your version of git by running

SYNOPSIS

DESCRIPTION

…​ git reset [-q] [—pathspec-from-file= [—pathspec-file-nul]] [ ]

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

After running git reset

Interactively select hunks in the difference between the index and (defaults to HEAD ). The chosen hunks are applied in reverse to the index.

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.

Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.

See «Reset, restore and revert» in git[1] for the differences between the three commands.

OPTIONS

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].

EXAMPLES

Somebody asks you to pull, and the changes sound worthy of merging.

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.

Rewind the master branch to get rid of those three commits.

Switch to topic/wip branch and keep working.

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.

Merge a topic branch into the current branch, which resulted in a fast-forward.

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.

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.

You can repeat steps 2-4 multiple times to break the original code into any number of commits.

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.

Источник

Доходчивое объяснение 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

Основные параметры

Чтобы продемонстрировать это, продолжим работать в репозитории, созданном ранее для примера с тремя деревьями. Сначала внесем в репозиторий некоторые изменения. Выполните в нем следующие команды:

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

—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:

Предпосылки:

Установка 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.

Источник