Работа с собственным репозиторием

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

Для начала создадим несколько коммитов:

Напишем текущее время в README.md

nano README.md

Добавим изменения файла README.md в коммит:

git add .

Теперь создадим второй коммит с этими изменениями:

git commit - m "second commit"

Отправим наш коммит на GitHub:

git push

Как и в прошлый раз надо ввести e-mail и токен.

Давайте перейдем на сайт GitHub и посмотрим на изменения.

Текущее состояние репозитория изменилось. Файл README.md соответствует тем изменениям, которые мы в него внесли. И обратите внимание, что в истории коммитов появился третий коммит - это наш текущий "второй" коммит, а "третий" он потому, что как мы говорили ранее, самый первый коммит сделал за нас сам git, когда создавал репозиторий.

Давайте сделаем еще пару коммитов и затем перейдем к навигации по ним.

Изменим файл README.md снова актуализировав время, добавим его в коммит и создадим третий коммит:

nano README.md

git add .
git commit -m "third commit"

И сразу не отправляя изменения на удаленный репозиторий сделаем и четвертый коммит:

nano README.md

git add .
git commit -m "4th commit"

А вот после этого уже отправим (запушим) изменения:

git push

Посмотрим на сайте GitHub что изменилось.

Все так как мы и ожидали, текущее состояние репозитория это то состояние файла README.md, которое мы изменили последним. Однако не смотря на то, что git push мы делали только один раз, после "четвертого" коммита, коммитов стало пять. Т.е. в один push вошло сразу два коммита "третий" и "четвертый". Это связано с тем, что git push не добавляет ничего в состояние репозитория, а только синхронизирует локального клона репозитория с удаленным клоном. Т.е. мы можем накапливать коммиты в течение рабочего дня, а затем одним пушем отправить их на GitHub, перед тем как пойти домой.

Посмотрим как выглядят текущие коммиты у нас в локальном репозитории. Введем:

git log

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

Кроме того обратите внимание что последний коммит имеет название HEAD - голова.

Теперь давайте перейдем к какому-нибудь из прошлых коммитов. Это делается командой git checkout hash <строка коммита>. Перейдем, например, к третьему коммиту:

git checkout 89453ef440149e38a3f397415c1b7b58deec9c16

Давайте посмотрим какое сейчас содержание файла README.md:

nano README.md

Как вы видите, указано время "12:10" что соответствует нашему третьему коммиту т.е. все так как мы и хотели. Однако логика команды git checkout состоит в том, что после переключения на старый коммит, он создает новую ветку, с новым HEAD, и нам надо что-то с этим делать. Или продолжить эту новую ветку и работать в ней, или вернуться на свою старую ветку main и продолжить работу там.

Давайте рассмотрим оба эти случая.

Вернемся на начальную ветку командой и посмотрим логи:

git checkout main

git log

Лог такой же как и был до этого. Т.е. все вернулось к 4му коммиту. Теперь мы можем продолжать работать как и было и все новые коммиты будут пристыковываться к 4-му.

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

Для того чтобы удалить коммиты выше определенного, надо ввести команду:

git reset <hash коммита>

Введем hash второго коммита и получим:

Теперь давайте запушим эти изменения на GitHub, обратите внимание что делать это надо с опцией force:

git push --force

Теперь на GitHub у нас следующая картина:

Т.е. все соответствует локальному репозиторию, а все коммиты новее второго удалены. Обратите внимание, что команду git reset надо делать из HEAD, а не после git checkout. Т.е. можно сначала найти правильный коммит при помощи git checkout, потом надо вернуться обратно в HEAD, и только потом отрезать новые коммиты командой git reset.

Теперь все наши следующие коммиты будут выстраиваться дальше в основную ветку main.