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

Кто-то просит вас выполнить получение, и изменения выглядят достойными слияния.

Однако вы уже изменили индекс (т.е. ваш индекс не соответствует коммиту HEAD). Но вы знаете, что получение, которое вы собираетесь выполнить, не затрагивает frotz.c или filfre.c, поэтому вы отменяете изменения индекса для этих двух файлов. Ваши изменения в рабочем каталоге остаются там.

Затем вы можете выполнить получение и слияние, оставив изменения в frotz.c и filfre.c всё ещё в рабочем каталоге.

Это чаще всего делается, когда вы вспомнили, что только что закоммиченное неполно, или вы сделали опечатку в сообщении коммита, или и то, и другое. Оставляет рабочий каталог таким, каким он был до "reset".

Внесите исправления в файлы рабочего каталога.

"reset" копирует старую голову в .git/ORIG_HEAD; переделайте коммит, начиная с его сообщения журнала. Если вам не нужно дополнительно редактировать сообщение, вы можете вместо этого указать параметр -C.

Вы сделали несколько коммитов, но понимаете, что они были преждевременными для ветки master. Вы хотите продолжить их доработку в тематической ветке, поэтому создайте ветку topic/wip от текущего HEAD.

Перемотайте ветку master назад, чтобы избавиться от этих трёх коммитов.

Переключитесь на ветку topic/wip и продолжайте работу.

Последние три коммита (HEAD, HEAD^ и HEAD~2) были плохими, и вы больше никогда не хотите их видеть. Не делайте этого, если вы уже передали эти коммиты кому-то ещё. (О последствиях такого действия см. раздел "ВОССТАНОВЛЕНИЕ ПОСЛЕ ПЕРЕМЕЩЕНИЯ ВЫШЕСТОЯЩЕЙ ВЕТКИ" в git-rebase[1].)

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

"pull" не создал коммит слияния, поэтому git reset --hard, который является синонимом git reset --hard HEAD, очищает беспорядок в файле индекса и рабочем каталоге.

Слияние тематической ветки с текущей веткой, которое привело к перемотке вперёд.

Но вы решили, что тематическая ветка ещё не готова для публичного использования. "pull" или "merge" всегда оставляют исходную верхушку текущей ветки в ORIG_HEAD, поэтому жёсткий сброс на неё возвращает ваш файл индекса и рабочий каталог в то состояние и сбрасывает верхушку ветки на этот коммит.

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

После изучения результата слияния вы можете обнаружить, что изменения в другой ветке неудовлетворительны. Выполнение git reset --hard ORIG_HEAD вернёт вас туда, где вы были, но отбросит ваши локальные изменения, чего вы не хотите. git reset --merge сохраняет ваши локальные изменения.

Этот коммит будет удалён, поэтому подойдёт временное сообщение журнала.

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

На этом этапе файл индекса всё ещё содержит все изменения WIP, которые вы закоммитили как snapshot WIP. Это обновляет индекс, чтобы показать ваши файлы WIP как незакоммиченные.

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

Это фиксирует все остальные изменения в индексе.

Снова добавляет файл в индекс.

Это фиксирует ваши первые правки в branch1.

В идеальном мире вы могли бы понять, что более ранний коммит не относится к новой теме, когда создавали и переключались на branch2 (т.е. git switch -c branch2 start), но никто не совершенен.

Но вы можете использовать reset --keep, чтобы удалить нежелательный коммит после того, как переключились на branch2.

Сначала сбросьте историю на один коммит назад, чтобы удалить исходный коммит, но оставить рабочий каталог со всеми изменениями. -N гарантирует, что любые новые файлы, добавленные с HEAD, по-прежнему отмечены, чтобы git add -p мог их найти.

Затем мы интерактивно выбираем части сравнения для добавления с помощью возможности git add -p. Он будет спрашивать вас о каждой части сравнения по порядку, и вы можете использовать простые команды, такие как "yes, include this", "No don’t include this" или даже очень мощную возможность "edit".

Когда вы удовлетворены частями, которые хотите включить, вы должны проверить, что было подготовлено для первого коммита, с помощью git diff --cached. Это показывает все изменения, которые были перемещены в индекс и вот-вот будут закоммичены.

Затем зафиксируйте изменения, хранящиеся в индексе. Параметр -c указывает предварительно заполнить сообщение коммита из исходного сообщения, с которого вы начали в первом коммите. Это полезно, чтобы избежать повторного ввода. HEAD@{1} — это специальное обозначение коммита, на котором HEAD находился до исходного сброса (1 изменение назад). Дополнительные сведения см. в git-reflog[1]. Вы также можете использовать любую другую допустимую ссылку на коммит.

Вы можете повторять шаги 2-4 несколько раз, чтобы разбить исходный код на любое количество коммитов.

Теперь вы выделили многие изменения в отдельные коммиты и можете больше не использовать режим патча git add, чтобы выбрать все оставшиеся незакоммиченные изменения.

Ещё раз проверьте, чтобы убедиться, что вы включили то, что хотели. Вы также можете проверить, что git diff не показывает никаких оставшихся изменений для последующей фиксации.

И наконец, создайте финальный коммит.