Head detached from как исправить

git checkout master

git checkout -- path/to/foo

34

git commit -m "....."
git branch my-temporary-work
git checkout master
git merge my-temporary-work

9

3

  git checkout master

git branch  temp
git checkout master
git merge temp

2

7

git stash
git checkout master   # Fix the detached head state
git stash pop         # Or for extra safety use 'stash apply' then later 
                      #   after fixing everything do 'stash drop'

4

$ git commit -m "..."
[detached HEAD 1fe56ad] ...

$ git checkout master
Switched to branch 'master'

$ git cherry-pick 1fe56ad
[master 0b05f1e] ...

6

git checkout myfile

git reset --hard HEAD^

1

3

0

1

git checkout <some-commit_number>

git add .
git commit -m "some message"

 git push origin HEAD:<name-of-remote-branch>

1

git checkout -b detached-head

git branch -D master

git branch -M master old-master

git branch -M detached-head master

0

git branch -f myStuckBranch HEAD
git checkout myStuckBranch

git fetch
git branch -f master origin/master  -- err yeah don't just ignore what's been going on remotely - eg point my master at the real master
git merge master -- merge the changes into my local branch

4

1

1

git pull origin master

1

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

Git. Урок 4.
Перемещение курсора и отмена изменений. Команды git restore, git rm, git reset, git checkout, git commit, git revert.

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

• 

• 

  Команды: git restore, git rm, git reset, git checkout, git commit, git revert.

Оглавление

ТЕОРЕТИЧЕСКИЙ БЛОК

Сегодня мы познакомимся с командами, которые позволят удалять и восстанавливать файлы в рабочей копии и индексе, отменять изменения на уровне целых коммитов, возвращаться в прошлое нашего репозитория и манипулировать указателем HEAD.

Удаляем и восстанавливаем файлы правильно. Команды git rm и git restore.

Начнем с удаления файлов. У читателя может возникнуть вопрос: почему нельзя просто взять и переместить файл из репозитория в корзину, как мы привыкли это делать с обычными файлами? Давайте разбираться.

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

1. Отслеживаемый.

1. Измененный (неподготовленный к коммиту).
2. Подготовленный к коммиту.

2. Неотслеживаемый.

Когда мы делаем файл отслеживаемым или подготавливаем его к коммиту, информация об этом файле записывается в индекс (файл .git/index). Эта информация никуда не денется, даже если мы удалили файл из рабочей копии. Рассмотрим пример. Допустим, мы выполним следующие действия:

1. Создадим файл sample.txt и внесем в него какие-то изменения;
2. Сделаем его отслеживаемым;
3. Удалим файл sample.txt;
4. Сделаем коммит;

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

В Git существует специальная команда, чтобы удалять файлы “правильно”.

Команда git rm

Внимательный читатель спросит: но почему нельзя удалить файл из репозитория обычным образом, а затем добавить изменения в индекс командой git add и сделать коммит? На самом деле можно. Команда git rm является сокращением вышеописанных действий. Ее применение считается более правильным, поскольку она короче и красивее. Давайте рассмотрим небольшой пример:

# Удалим файл обычным образом
$ rm sample.txt
$ git status
On branch main
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    sample.txt
$ git add -A

# И вся последовательность команд выше эквивалентна всего одной:
$ git rm sample.txt
rm 'sample.txt'

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        deleted:    sample.txt

# Осталось только сделать коммит, чтобы сохранить изменения:
$ git commit -m "L-04: Deleted sample.txt"
[main f34705a] L-04: Deleted sample.txt
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 sample.txt

Итак, мы разобрались с удалением файлов. Но что, если мы захотим восстановить файл после удаления или изменения в рабочей копии или индексе? Для этого существует команда git restore. Давайте разберем ее подробнее.

Команда git restore

С помощью команды git restore можно сделать неотслеживаемыми файлы, которые вы случайно добавили командой git add. Приведем пример:

# Допустим у нас есть некоторый репозиторий, просмотрим статус файлов:
$ git status
On branch main
Untracked files:
  (use "git add <file>..." to include in what will be committed)
       file_to_commit.txt
       another_file_to_commit.txt
       file_not_for_commit.txt

# Для простоты добавим все файлы в индекс разом
$ git add -A

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   file_to_commit.txt
        new file:   another_file_to_commit.txt
        new file:   file_not_for_commit.txt

# А теперь восстановим файл “file_not_for_commit.txt” в области индекса. Тогда источником станет последний коммит, а в нем такого файла нет (файл же новый). Поэтому файл будет удален из области индекса. Кстати, можно заметить, что даже Git подсказывает нам: “use "git restore --staged <file>..." to unstage”. 

$ git restore --staged file_not_for_commit.txt

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   another_file_to_commit.txt
        new file:   file_to_commit.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        file_not_for_commit.txt

# Для справки: в данном случае эквивалентной командой будет:
$ git rm --cached file_not_for_commit.txt
rm 'file_not_for_commit.txt'

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   another_file_to_commit.txt
        new file:   file_to_commit.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        file_not_for_commit.txt

Подведем итогИтак, мы теперь умеем удалять и восстанавливать файлы из индекса и рабочей копии.
1. Чтобы удалить файл правильно, воспользуйтесь командой git rm. Она удалит файл из индекса и из рабочей копии.

1. Вариант git rm –cached удалит файл из индекса и переместит его в категорию Untracked.
2. По своей сути git rm <filename> представляет сокращение двух команд: rm <filename> и git add <filename>.

2.Чтобы восстановить файл в рабочей копии и/или индексе, воспользуйтесь командой git restore.

1. Ключ –source=<tree> позволит вам указать место, откуда брать файл для восстановления. По умолчанию этим местом является область индекса.
2. По умолчанию файл восстанавливается в рабочей копии, но вы можете восстановить файл в области индекса с ключом –staged или одновременно в области индекса и в рабочей копии, передав ключи –staged –worktree. В этом случае по умолчанию (если вы не передали ключ –source) файл будет взят из коммита, на который указывает HEAD.

Просмотр старых коммитов и перемещение указателя HEAD

Итак, пришло время разобраться, каким образом можно перемещать HEAD (и другие указатели тоже) и что это дает. Для начала нужно прояснить несколько важных аспектов, которые мы уже упоминали, но не обращали ваше внимание на них:

1. Весь репозиторий – это древовидный граф, ноды которого – наши коммиты, а ребра – родительские отношения между коммитами.
2. HEAD – это указатель (то есть ссылка на один из коммитов), главное назначение которого – определять, в каком состоянии находится рабочая копия. На какой коммит указывает HEAD – в таком состоянии файлы и находятся в рабочей области.
3. Обычно HEAD указывает не на определенный коммит, а на указатель ветки, который в свою очередь указывает на конкретный коммит.
4. HEAD можно перемещать: при перемещении указателя файлы в рабочей копии изменятся так, чтобы соответствовать коммиту, на который указывает HEAD.
5. Указывая путь до чего бы то ни было, вы можете использовать как абсолютные указатели, например, хэш коммита или имя ветки, так и относительные. Вспомним, как пользоваться относительными указателями:

1. Знак ^ означает “предыдущий”. Например путь HEAD^ означает “предыдущий коммит перед тем, на который указывает HEAD“
2. Знак ~ позволяет вам указать число коммитов. Например, запись HEAD~7 означает “7 коммитов назад от коммита, на который указывает HEAD“.

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

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

Команда git checkout

Можно заметить, что синтаксис совершенно такой же, как и в переключении ветки из предыдущего урока. Все верно, ведь переключение ветки – ни что иное, как передвижение указателя HEAD с указателя одной ветки на указатель другой. Чтобы подробно разобраться, что происходит при передвижении указателя, давайте рассмотрим пример. Изначально у нас есть такой репозиторий.

Серыми овалами обозначены коммиты, текст на них – часть хэша соответствующего коммита. Коричневым прямоугольником обозначен указатель ветки: она у нас одна и называется main. Белым прямоугольником обозначен указатель HEAD, иногда его называют курсором. Его-то мы и будем двигать. Давайте попробуем сдвинуть HEAD на два коммита назад (то есть на коммит с хэшем 90ab…) и посмотрим, что будет.

$ git checkout HEAD~2
Note: switching to 'HEAD~2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 90abf7e L-04: Fixing gradient bug

Предупреждение Git мы разберем чуть ниже, а сейчас давайте посмотрим, в каком состоянии мы оказались.

Как видно из рисунка, указатель HEAD сейчас действительно передвинут на два коммита назад. Но указатель ветки main остался на месте и все еще указывает на последний коммит. Такое состояние, когда HEAD указывает не на указатель ветки, а непосредственно на сам коммит, называется detached head.

“

Detached head (англ. дословно – отрубленная голова, имеется в виду указатель HEAD, отключенный от графа) – состояние, при котором указатель HEAD не указывает ни на одну из веток репозитория, а ссылается непосредственно на сам коммит.

Если прочесть предупреждение Git выше, можно заметить, что он сообщает нам, что мы оказались в состоянии detached head. Давайте рассмотрим несколько особенностей этого состояния:

2.1. История выводится не полностью

Действительно, если мы из текущего состояния выполним команду git log:

$ git log --pretty=oneline
90abf7ef211229adfa4cb75e0f35a0561dd15467 (HEAD)  L-04: Fixing gradient bug
3a3bb706651a19013822c09e5c70c9fc425a66dc L-04: Adding gradient function
d469222a7a760daa3cd56747e216e3de2a3343ee L-04: Initial commit

Видно, что вывелись только те коммиты, которые были сделаны позже коммита, на котором сейчас стоит HEAD. Если же мы хотим просмотреть всю историю, нужно воспользоваться ключом –all:

$ git log --all --pretty=oneline
62aa1ffe0587c7ffa3d865a3233da04d65818030 (main) L-04: Adding autograd
33ff7207fed9cbb34c9f3334249ef0707477f278 L-04: Adding neuron class
90abf7ef211229adfa4cb75e0f35a0561dd15467 (HEAD)  L-04: Fixing gradient bug
3a3bb706651a19013822c09e5c70c9fc425a66dc L-04: Adding gradient function
d469222a7a760daa3cd56747e216e3de2a3343ee L-04: Initial commit

Тогда нам видна полная история репозитория. Если присмотреться, то можно увидеть, что напротив первого сверху коммита в скобках написано main. Так Git сообщает нам, что на данный коммит указывает ветка main. Аналогично с третьим сверху коммитом: напротив него написано HEAD. Это означает, что HEAD указывает на этот коммит.

2.2. Как переключиться обратно

Вам вовсе необязательно смотреть полную историю каждый раз, когда вы хотите вернуться обратно на ветку main. В предыдущем уроке мы рассматривали команду git checkout – и говорили, что с ее помощью можно вернуться на ветку, с которой мы переключились на текущую. Так вот, эта команда работает не только для веток, но и для любых перемещений HEAD. Если мы хотим перенести HEAD обратно, достаточно выполнить:

$ git checkout -
Previous HEAD position was 90abf7e L-04: Fixing gradient bug
Switched to branch 'main'

Как видно по выводу Git, мы успешно вернулись обратно на ветку main и вышли из состояния detached head.

У данного способа есть один минус: если вы “прыгали” по коммитам репозитория несколько раз, то git checkout – вернет вас на последний коммит, на котором вы были, а не на ветку main. В данном случае поможет простое и гениальное:

$ git checkout main
Previous HEAD position was 90abf7e L-04: Fixing gradient bug
Switched to branch 'main'

То есть мы напрямую указываем Git, что хотим переключиться на ветку main (или любую другую), таким образом выходя из состояния detached head.

2.3. Зачем может понадобиться переключать указатель на старые коммиты, и важные особенности состояния “detached head”.

На самом деле, все зависит от конкретной задачи и проекта, над которым вы работаете. Вообще состояние detached head на практике используется довольно-таки редко. Но все же можно привести несколько примеров использования этого состояния:

Пример 1
Самый банальный пример – просмотр файлов в определенном коммите. Допустим, вы хотите просмотреть содержимое файла main.py в коммите с определенным хэшем.
Просто выполните:

# Команда cat выводит в консоль содержимое файла.
$ git checkout 5df3f7e
$ cat main.py
print(“Hello world”)

Таким образом, вы можете просмотреть содержимое любого, когда либо закоммиченного файла, что бывает довольно удобно.

Пример 2
Кроме того, когда вы работаете над большим проектом, может быть нужно вернуться на несколько коммитов назад и создать свою ветку оттуда: например, чтобы протестировать экспериментальную функцию в том состоянии проекта. Сделать это можно так:

# Переключим указатель HEAD на определенный коммит:
$ git checkout 9a4e88b

# Теперь создадим новую ветку
$ git checkout -b feature
Switched to a new branch 'feature'

# Добавим файл и сделаем коммит
$ echo "just docs we forgot to put" > docs.md
$ cat docs.md
just docs we forgot to put

$ git add -A
$ git commit -m "L-04: Adding docs"
[feature d5e3273] L-04: Adding docs
 1 file changed, 1 insertion(+)
 create mode 100644 docs.md

Теперь у нас есть целая ветка feature, которая берет свое начало с коммита 9a4e88b. На ней мы можем проводит эксперименты с тем состоянием репозитория, которое было несколько коммитов назад, не боясь навредить остальной части репозитория.

Заметьте, что когда мы создали и переключились на ветку, мы вышли из состояния detached head. Если бы мы сделали коммит, не создавая для этого ветки, этот коммит оказался бы “оторванным” от истории: на него не ссылалась бы ни одна ветка, а в выводе истории (даже полной) его не было бы видно. Иначе говоря, если бы мы сделали коммит без ветки, мы бы смогли получить к нему доступ только запомнив его хэш наизусть.

Поэтому с состоянием detached head следует быть очень осторожным: если забыть создать новую ветку и начать делать коммиты, их можно с легкостью потерять.

На самом деле, если вы сделали несколько коммитов из состояния detached head и забыли создать ветку, ничего страшного: ветку можно создать прямо сейчас. Рассмотрим пример с тем же репозиторием:

# Переключимся в состояние “detached head” на ветке main.
$ git checkout d5e3273

# Теперь мы создадим несколько коммитов, исключительно для примера:
$ echo 'print('hello world')' > hello_world.py
$ echo 'print('Hi')' > say_hi.py
$ echo 'Some text file' > about.txt
$ git add hello_world.py
$ git commit -m "L-04: Adding hello_world.py"
[detached HEAD d013c75] L-04: Adding hello_world.py
 1 file changed, 1 insertion(+)
 create mode 100644 hello_world.py

$ git add say_hi.py
$ git commit -m "L-04: Adding say_hi.py"
[detached HEAD 58f8c22] L-04: Adding say_hi.py
 1 file changed, 1 insertion(+)
 create mode 100644 say_hi.py

$ git add about.txt
$ git commit -m "adding about.txt"
[detached HEAD 7c10724] L-04: Adding about.txt
 1 file changed, 1 insertion(+)
 create mode 100644 about.txt

# А сейчас мы вспомнили, что сделали несколько коммитов в состоянии “detached head” и испугались, что потеряем их. Но не стоит бояться, можно просто создать ветку прямо сейчас:
$ git checkout -b feature
Switched to a new branch 'feature'

# И чтобы убедиться, что мы не потеряли ни одного коммита, давайте взглянем на историю ветки feature
$ git log --pretty=oneline main..feature
7c10724b12dba69ed1acf4c6fef804c251f7c290 (HEAD -> feature) L-04: Adding about.txt
58f8c226952d500df7a9c2f798011ab20165a286 L-04: Adding say_hi.py
d013c75418ac71ca8f4578583aa23d7567dab332 L-04: Adding hello_world.py
d5e327368d12d6e5ef5b04e16af1d96319069805 L-04: Adding docs

Даже в состоянии detached head коммиты сохраняют родительские отношения, то есть каждый коммит знает, кто его предшественник. Поэтому мы в любой момент можем восстановить их последовательность, если найдем крайний коммит в данной цепочке. То есть для нас главное не забыть создать ветку, находясь в состоянии detached head. А вот создать ее можно в любой момент: до того, как мы сделаем первый коммит из этого состояния, или в любой другой момент – не важно, главное сделать это до переключения на другую ветку или коммит. Тогда у нас будет ссылка на крайний коммит ветки, а по его родителям мы сможем определить всю последовательность.

Подведем итог

1. Указатель HEAD можно перемещать на разные коммиты, точно так же, как мы перемещали его между ветками. Для этого нужно использовать команду git checkout.
2. Когда мы перемещаем HEAD с указателя ветки на коммит, мы попадаем в состояние detached head.
3. В состоянии detached head стоит быть осторожным: если планируете делать коммиты, лучше сразу создайте ветку командой git checkout -b <имя ветки>.
4. Если вы сделали несколько коммитов из состояния detached head, забыв создать ветку – ничего страшного, ветку можно создать в любой момент.
5. Обычно detached head используется редко, но вы можете использовать его, чтобы просматривать старые версии файлов или экспериментировать с предыдущими версиями проекта.

Откат коммитов. Команда git revert.

Пожалуй одна из самых важных частей в изучении Git – научиться откатываться к предыдущим коммитам. Смысл отката мы обсуждали в предыдущих уроках: ваш проект может перестать работать по непонятным вам причинам после внесения некоторых изменений в код, в таком случае важно быстро вернуть все к рабочему состоянию и только потом заниматься поиском ошибки. В этом-то случае нам и поможет откат коммитов и команда git revert.

Суть работы данной команды в том, что она создает новый коммит, который отменяет изменения внесенные в переданном коммите (последовательности коммитов).

Команда git revert

Команда git revert очень важна, поэтому давайте разберем, как с ней работать. Рассмотрим самый простой пример, в котором у нас не возникнет файловых конфликтов. Допустим, мы хотим отменить изменения предпоследнего коммита. Главное, что здесь нужно запомнить – это что у нас не должно быть незакоммиченых изменений в рабочей директории, ведь мы все-таки делаем реверт-коммит. Если у вас есть таковые, лучшим решением станет закоммитить (или удалить) все изменения, и только потом делать реверт.

# Выполним реверт предпоследнего коммита. Кстати, такой реверт никогда не вызовет конфликтов.

$ git revert HEAD~1

# Как только мы выполним команду, будет открыт консольный редактор, чтобы вы могли отредактировать сообщение нового коммита. Можно что-то дописать, можно сразу закрыть редактор сочетанием Ctrl+X (здесь приведено сочетание для редактора “nano”). Решать вам. В нашем случае окно редактора будет выглядеть так.

Revert "L-04: Addit docs.txt"

This reverts commit aadfbc3a6756289727e56ac3de59004e66e40033.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Your branch is up to date with 'origin/master'.
#
# Changes to be committed:
#       modified:   docs.txt
#



^G Get Help  ^O Write Out ^W Where Is  ^K Cut Text  ^J Justify   ^C Cur Pos
^X Exit      ^R Read File ^ Replace   ^U Paste Text^T To Spell  ^_ Go To Line

# После закрытия редактора, в терминал будет выведена информация об успешном реверте коммита

[main e933971] Revert "addit docs.txt"
 1 file changed, 1 insertion(+), 1 deletion(-)

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

Иногда при отмене изменений может возникнуть ситуация, когда в файл в рабочей копии были внесены изменения с момента коммита находится не в том же состоянии, как в коммите, который мы отменяем. Звучит сложно, поэтому давайте приведем пример. Допустим, у нас есть следующий репозиторий.

В каждом из вышеуказанных коммитов всего один файл: docs.md. Над хэшем каждого коммита на рисунке указано содержимое docs.md, которое было внесено в данный коммит.

Теперь, когда перед глазами у вас есть диаграмма, давайте разберемся, в каком случае при откате возникнет конфликт файлов. На самом деле, конфликт возникнет при откате любого, кроме самого последнего коммита. Как мы уже говорили, при реверте коммита, его изменения отменяются, то есть файлы возвращаются к состоянию предыдущего коммита. Например, если мы попробуем откатить коммит 33ff, то содержимое файла docs.md изменится с

Содержимое docs.md, коммит 33ff

Содержимое docs.md, коммит 90ab

Но ведь в последнем коммите, т.е. в рабочей копии находится файл, содержимое которого

что совсем не соответствует содержимому коммита, который мы откатываем. То есть с момента того коммита мы уже успели изменить файл docs.md, и теперь Git не очень понимает, как именно делать откат:

1. оставить файл в рабочей копии нетронутым или,
2. наоборот, заменить файл в рабочей копии на файл после отката.

Поэтому и возникает конфликт. Git напрямую спрашивает у нас: “Какой файл мне оставить?”. На практике это выглядит вот так:

# Пробуем откатить коммит .
$ git revert 33ff381
Auto-merging docs.md
CONFLICT (content): Merge conflict in docs.md
error: could not revert 33ff381... L-04: Adding info to docs
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

В следующем уроке, когда мы будем говорить о слиянии веток, мы научимся разрешать файловые конфликты.

Кстати, если вы попали в ситуацию, когда Git сообщил вам о конфликте файлов, а вы такого не ожидали, или вы просто передумали делать откат из-за конфликта, можете в любой момент выполнить git revert –abort. Это остановит откат, и вы сможете спокойно разобраться, откуда возникает конфликт.

Подведем итог

1. git revert – команда, отменяющая изменения переданного коммита. Она заменяет файлы в рабочей копии на файлы предка переданного коммита, а затем делает коммит, чтобы сохранить изменения.
2. Иногда во время отката возникают конфликты. Их не стоит бояться, но нужно быть внимательным и разобраться, откуда возникает конфликт.
3. Если вы столкнулись с конфликтом во время отката и передумали продолжать git revert, выполните команду git revert –abort. Она вернет все как было и отменит откат.
4. В сообщении реверт-коммита следует указывать полезную информацию: зачем вы сделали откат, каким образом вы сливали файлы, если были конфликты, и т.д.

Удаление и объединение коммитов. Команда git reset.

Помните, мы говорили про команду git checkout и перемещение указателя HEAD? Тогда мы перемещали только сам указатель HEAD и попадали в состояние detached head. Команда git reset позволяет нам перемещать указатель ветки вместе с указателем HEAD. Давайте разберем эту команду подробнее.

Команда git reset

Чтобы лучше понять смысл этой команды приведем граф репозитория. Изначально он выглядел так.

Теперь выполним “мягкий” reset последних двух коммитов.

$ git reset --soft HEAD~2

Теперь наш граф выглядит так.

Причем файлы в рабочей копии остались в том же состоянии, что и были в коммите 62aa.

Как видно из рисунка, Git создал новый указатель – ORIG_HEAD. Этот указатель создается при выполнении команды git reset и ссылается на тот коммит, от которого мы делали reset. Как мы увидим ниже, это очень полезный в работе с git reset указатель.

Кстати, если мы сейчас сделаем коммит:

$ git add -A
$ git commit -m “L-04: Reset commit”
[main 03953f8] L-04: Reset commit
 1 file changed, 3 insertions(+), 1 deletion(-)

То получим такую картину:

То есть наш коммит пойдет по ответвлению от исходной ветки main. Поэтому будьте внимательны, создавая новые коммиты.

Итак, теперь поговорим, как на практике используется git reset. В основном, все использование сводится к трем пунктам:

1. Редактирование/отмена последнего коммита.
2. Объединение нескольких коммитов в один.
3. Удаление коммитов.
4. Отмена изменений команды git reset.

Давайте подробно разберем каждый пункт.

4.1. Редактирование или отмена последнего коммита

Если вы случайно опечатались в сообщении последнего коммита, или хотите добавить в него файлов, то git reset поможет вам. Но прежде всего нам нужно разобрать новые ключи уже знакомой команды git commit. Они потребуются нам в дальнейшем.

Команда git commit

Теперь, когда мы познакомились с новыми ключами, можем перейти к редактированию последнего коммита. Последовательность действий в данной ситуации такая:

1. Откатиться к предпоследнему коммиту командой git reset –soft HEAD^
2. Добавить в коммит новые файлы, если вам это нужно, использовав команду git add.
3. Выполнить git commit -c ORIG_HEAD, если вы хотите отредактировать сообщение, или git commit -C ORIG_HEAD, если вы хотите оставить сообщение коммита без изменений.

Полезно знать
Кстати, данная последовательность команд идентична git commit –amend. Чтобы отредактировать последний коммит, следуйте инструкции:
1. Если вы хотите добавить в коммит файлы, то для начала добавьте их в индекс командой git add <имя файла>. Если не хотите, то проверьте, что проиндексированных изменений нет, иначе они будут добавлены в последний коммит.
2. Выполните

1. git commit –amend. Тогда откроется консольный редактор, где вы сможете отредактировать сообщение последнего коммита.
2. git commit –amend -m “<новое сообщение>”. Тогда сообщение последнего коммита будет заменено на <новое сообщение>.

В случае, если же вы хотите насовсем удалить последний коммит, просто выполните

$ git reset --hard HEAD^
HEAD is now at c732f69 L-04: Adding more info to docs

Таким образом, последний коммит будет удален и не будет отображаться в логе. Тем не менее, вернуться к нему вы сможете по указателю ORIG_HEAD, который оставит Git.

4.2. Объединение нескольких коммитов в один.

Иногда на практике возникают ситуации, когда для удобства восприятия и красивой истории необходимо объединить несколько последних коммитов в один. Порядок действий тут почти такой же, как и в случае редактирования последнего коммита:

1. Выполните git reset –soft HEAD~n, где n это число коммитов, которые вы хотите объединить. Эта команда вернет указатель ветки на n коммитов назад, оставив изменения в индексе и рабочей копии нетронутыми. То есть после выполнения этой команды вы откатитесь на n коммитов назад, но все изменения внесенные этими коммитами останутся у вас в рабочей копии и индексе.
2. Выполните git commit -c ORIG_HEAD, а затем отредактируйте сообщение коммита должным образом. Эта команда сделает коммит всех изменений в индексе. То есть она сделает коммит, который по своему содержимому представляет объединение последних n коммитов.

Собственно, это все. То есть на самом деле мы просто откатили последние несколько коммитов, а затем создали новый коммит, который собирает в себе все их изменения. При этом изначальные коммиты никуда не делись. Их не будет видно в истории, но если вы помните их хэш, то в любой момент сможете переключиться на любой из них с помощью команды git checkout.

4.3. Удаление последних нескольких коммитов.

Пожалуй, самая простая ситуация. Чтобы удалить последние n коммитов, выполните

$ git reset --hard HEAD~n

Где n – это, конечно, какое-то конкретное число. После этого удаленные коммиты не будут выводиться в истории (совсем, даже с флагом –all).

4.4. Отмена изменений команды git reset.

Если вы каким-то образом случайно выполнили git reset и решили все вернуть, просто переместите указатель ветки обратно, использовав команду

Эта команда вернет указатель ветки на коммит, с которого вы делали git reset, и вы вернете все изменения, даже если использовали ключ –hard.

Подведем итог
Итак, мы выучили новую команду git reset. Она используется, чтобы перемещать указатель ветки по графу Git. На практике ее в основном применяют для

1. Редактирования или удаления последнего сделанного коммита.
2. Объединения последних нескольких коммитов в один.
3. Удаления последних нескольких коммитов.

После использования git reset, Git создаёт указатель ORIG_HEAD, который ссылается на коммит, с которого мы сделали reset.

Не стоит забывать, что даже если вы использовали git reset –hard, вы всегда можете вернуть все к изначальному состоянию, выполнив git reset ORIG_HEAD. Это вернет указатель ветки на коммит, с которого вы делали reset.

Различие команд git reset и git checkout и git revert

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

Изученные команды

Между git checkout, git reset и git restore есть несколько различий:

1. Команда git checkout <ссылка> похожа на git reset –hard <ссылка>: в обоих случаях перемещается HEAD и меняется рабочая копия. Однако есть и разница:.

1. Первое отличие состоит в том, что git checkout перемещает только HEAD, в то время как git reset перемещает HEAD и ветку, на которую указывает HEAD.
2. Еще одно отличие заключается в том, что git checkout проверяет, что у вас в рабочей копии нет измененных файлов, в то время как git reset просто заменяет все файлы без разбора.

В случае, когда мы находимся в состоянии detached head и у нас нет измененных файлов, эти две команды идентичны.

2. Команда git checkout <ссылка> <имя файла> также имеет общие черты с git reset <ссылка> <имя файла>. Отличие состоит в следующем:

git checkout <ссылка> <имя файла> изменяет и рабочую копию, и индекс, в то время, как git reset <ссылка> <имя файла> меняет только индекс. Кстати, идентичной командой для git checkout <ссылка> <имя файла> была бы команда git reset –hard <ссылка> <имя файла>, если бы ее можно было так использовать: это очень небезопасно для рабочей копии.

3. Команда git restore задумывалась как аналог git checkout <ссылка> <имя файла>. Тем не менее, между ними есть следующие отличия:

1. Используя git checkout <ссылка> <имя файла>, в качестве ссылки вы можете передать только определенный коммит, в то время как git restore может скопировать файл в рабочую копию прямо из индекса
2. Команда git checkout всегда копирует файлы одновременно и в рабочую копию, и в область индекса, что не всегда удобно. В свою очередь, git restore может принять ключи –staged и –worktree, определяющие, скопировать файл только в область индекса, только в рабочую копию, или сразу в оба места.

Для закрепления, давайте приведем таблицу сравнения команд git revert, git reset, git checkout и git reset по их взаимодействию с указателем HEAD, историей, индексом и рабочей копией.

ПРАКТИЧЕСКИЙ БЛОК

Задание. Библиотека Geometric Lib.

Сегодня было много теории, пора закрепить ее на практике. Мы снова воспользуемся командой git clone (как и в прошлом уроке). Напомним, что она копирует удаленный репозиторий к вам на компьютер.

Также напомним, что наш удаленный репозиторий представляет собой библиотеку на Python, которая позволяет высчитывать площади и периметры некоторых геометрических фигур.
Ссылка на библиотеку Geometric Lib на GitHub: https://github.com/smartiqaorg/geometric_lib

В этот раз в нашем репозитории появились еще две ветки, теперь его структура выглядит следующим образом:

К файлам добавилось три новых: triangle.py, rectangle.py и calculate.py. Первый содержит функции для вычисления периметра и площади треугольника, второй – то же для квадрата. В свою очередь, calculate.py объединяет функционал этих файлов: он предназначен для расчета площади и периметра переданной пользователем фигуры.

Задание. Условие.

Задание. Решение.

# п 1. Клонируем репозиторий и активируем локальные ветки
$ git clone https://github.com/smartiqaorg/geometric_lib
$ cd geometric_lib/
$ git branch --all
$ git checkout develop
$ git checkout feature
$ git branch --all

# п 2. Работаем с веткой feature: откатываем коммит
$ git checkout feature
$ git log
$ git revert HEAD
$ git log

# п 3. Работа с веткой develop: Объединение коммитов
$ git checkout develop
$ git log
$ git reset --soft HEAD~2
$ git log
$ git status
$ git commit -c ORIG_HEAD
$ git log

# п 4. Работа с веткой experiment: Перенос и удаление файлов
$ git checkout main
$ git checkout -b experiment
$ git restore --worktree docs/README.md --source develop
$ git status
$ git restore --worktree --staged calculate.py --source develop
$ git status
$ git add docs/README.md
$ git commit -m "L-04: Experimental commit"
$ git rm circle.py square.py 
$ git status
$ git commit -m "L-04: Deleted circle and square"

Более подробный разбор задания

Также на странице Задания и Ответы по курсу Git мы даем более подробный разбор текущего задания.
Приводим в нем не только команды Git, но и их консольный вывод, а также даем комментарии к каждой команде.

Как вам материал?

Читайте также