Git - это бесплатная распределенная система управления версиями с открытым исходным кодом, предназначенная для быстрой и эффективной обработки всего, от небольших до очень крупных проектов. Git прост в освоении, занимает мало места и обладает молниеносной производительностью. Он превосходит инструменты SCM, такие как Subversion, CVS, Perforce и ClearCase, с такими функциями, как дешевое локальное ветвление, удобные промежуточные области и несколько рабочих процессов.

Ветвление и слияние

Особенность Git, которая действительно отличает его от почти всех других SCM, - это его модель ветвления. Git позволяет и поощряет создание нескольких локальных веток, которые могут быть полностью независимыми друг от друга. Создание, слияние и удаление этих линий разработки занимает секунды. Это означает, что вы можете делать что-то вроде:

• Беспроблемное переключение контекста. Создайте ветку, чтобы опробовать идею, зафиксируйте несколько раз, вернитесь туда, откуда вы разветвились, примените патч, вернитесь туда, где вы экспериментируете, и объедините его.
• Кодовые строки на основе ролей. Имейте ветку, которая всегда содержит только то, что идет в производство, другую, в которую вы объединяете работу для тестирования, и несколько более мелких веток для повседневной работы.
• Функциональный рабочий процесс. Создавайте новые ветки для каждой новой функции, над которой вы работаете, чтобы вы могли легко переключаться между ними, а затем удаляйте каждую ветку, когда эта функция будет объединена с вашей основной строкой.
• Одноразовые эксперименты. Создайте ветку, чтобы поэкспериментировать, осознать, что она не будет работать, и просто удалите ее - отказавшись от работы - пока никто ее не увидит (даже если вы тем временем подтолкнули другие ветки).

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

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

Маленький и быстрый

Git работает быстро. В Git почти все операции выполняются локально, что дает огромное преимущество в скорости для централизованных систем, которым постоянно приходится где-то связываться с сервером. Git был создан для работы с ядром Linux, а это означает, что ему с самого первого дня приходилось эффективно обрабатывать большие репозитории.

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

Контрольный показатель

Давайте посмотрим, как общие операции сочетаются с Subversion, общей централизованной системой управления версиями, похожей на CVS или Perforce. Меньше - быстрее.

Для тестирования большие инстансы AWS были настроены в одной зоне доступности. Git и SVN были установлены на обеих машинах, репозиторий Ruby был скопирован на серверы Git и SVN, и на обоих выполнялись общие операции. В некоторых случаях команды не совпадают в точности. Здесь была предпринята попытка сопоставления по наименьшему общему знаменателю. Например, тесты «фиксации» также включают время для отправки запроса на Git, хотя в большинстве случаев вы фактически не отправляете запрос на сервер сразу после фиксации, когда две команды не могут быть разделены в SVN.

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

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

Распределённый

Одна из самых приятных особенностей любой распределенной SCM, включая Git, - это то, что она распределенная. Это означает, что вместо «проверки» текущей части исходного кода вы выполняете «клонирование» всего репозитория.

Множественные резервные копии

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

Любой рабочий процесс

Благодаря распределенной природе Git и превосходной системе ветвления можно относительно легко реализовать почти бесконечное количество рабочих процессов.

Рабочий процесс в стиле Subversion

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

Рабочий процесс диспетчера интеграции

Другой распространенный рабочий процесс Git включает в себя менеджера интеграции - одного человека, который фиксирует «благословенный» репозиторий. Затем ряд разработчиков клонируют данные из этого репозитория, отправляют их в свои собственные независимые репозитории и просят интегратора внести их изменения. Это тип модели разработки, который часто встречается в репозиториях с открытым исходным кодом или GitHub.

Рабочий процесс диктатора и лейтенантов

Для более масштабных проектов часто эффективен рабочий процесс разработки, подобный процессу ядра Linux. В этой модели некоторые люди («лейтенанты») отвечают за определенную подсистему проекта и объединяют все изменения, связанные с этой подсистемой. Другой интегратор («диктатор») может получать изменения только от своих лейтенантов, а затем отправлять их в «благословенный» репозиторий, из которого все затем клонируют снова.

Гарантия данных

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

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

Плацдарм

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

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

 

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

Конечно, Git также позволяет легко игнорировать эту функцию, если вам не нужен такой контроль - просто добавьте '-a' в свою команду фиксации, чтобы добавить все изменения во все файлы в промежуточную область.

Бесплатно и с открытым исходным кодом

Git выпущен под лицензией GNU General Public License версии 2.0, которая является лицензией с открытым исходным кодом. Проект Git решил использовать GPLv2, чтобы гарантировать вам свободу обмена и изменения бесплатного программного обеспечения - чтобы убедиться, что программное обеспечение является бесплатным для всех его пользователей.

Учебные курсы по Git

• This email address is being protected from spambots. You need JavaScript enabled to view it. - Учебник по Git 
• Основы Git

• Hexlet - Введение в Git

  • Git Cheat Sheet 
  • Соглашение о коммитах

• Git и GitHub Курс Для Новичков

• Stepik - Телеграм-боты на Python и AIOgram
• • Как работает Git
  • Конфигурирование Git
  • Коммиты
  • Создание учетной записи GitHub
  • Доступ к GitHub по SSH
  • Синхронизация локального репозитория с GitHub
• YouTube

  • Git. Большой практический выпуск (Артем Матяшов)

  • Основные аспекты современной командной разработки. 1.1. Курс «Git для начинающих» (Слёрм)

Отказ от использования паролей

В июле 2020 года мы объявили о своем намерении требовать использования аутентификации на основе токенов (например, токен личного доступа, OAuth или токен установки приложения GitHub) для всех аутентифицированных операций Git. С 13 августа 2021 г. мы больше не будем принимать пароли учетных записей при аутентификации операций Git на GitHub.com.

Затронутые рабочие процессы

• Доступ к Git из командной строки

Настольные приложения, использующие Git (GitHub Desktop не затрагивается) Любые приложения/сервисы, которые получают доступ к репозиториям Git на GitHub.com напрямую, используя ваш пароль. Это изменение не коснется следующих клиентов: Если для вашей учетной записи включена двухфакторная аутентификация, вам уже необходимо использовать аутентификацию на основе токена или SSH. Если вы используете GitHub Enterprise Server, мы не объявляли о каких-либо изменениях в нашем локальном предложении. Если вы поддерживаете приложение GitHub, приложения GitHub не поддерживают аутентификацию по паролю.

Мы описали нашу мотивацию, когда объявили об аналогичных изменениях в аутентификации с помощью API, следующим образом:

В последние годы клиенты GitHub воспользовались рядом улучшений безопасности GitHub.com, таких как двухфакторная аутентификация, оповещения о входе в систему, проверенные устройства, предотвращение использования скомпрометированных паролей и поддержка WebAuthn. Эти функции затрудняют злоумышленнику получение пароля, который повторно использовался на нескольких веб-сайтах, и использование его для попытки получить доступ к вашей учетной записи GitHub. Несмотря на эти улучшения, по историческим причинам клиенты без включенной двухфакторной аутентификации могли продолжать аутентифицировать операции Git и API, используя только свое имя пользователя и пароль GitHub.

Начиная с 13 августа 2021 г. мы больше не будем принимать пароли учетных записей при аутентификации операций Git и будем требовать использования аутентификации на основе токенов, например токена личного доступа (для разработчиков) или токена установки приложения OAuth или GitHub (для интеграторов). для всех аутентифицированных операций Git на GitHub.com. Вы также можете продолжать использовать SSH-ключи там, где вам удобно.

Токены предлагают ряд преимуществ в плане безопасности по сравнению с аутентификацией на основе пароля:

• Уникальные — токены специфичны для GitHub и могут генерироваться для каждого использования или для каждого устройства.
• Возможность отзыва — токены могут быть отозваны по отдельности в любое время без необходимости обновления незатронутых учетных данных.
• Ограниченный — токены могут иметь узкую область действия, чтобы разрешить только доступ, необходимый для варианта использования.
• Случайный выбор — токены не подвержены типам словаря или попыткам грубой силы, которые могут быть у более простых паролей, которые вам нужно помнить или регулярно вводить.

Что вам нужно сделать сегодня

• Для разработчиков: если вы используете пароль для аутентификации операций Git с GitHub.com сегодня, вы должны начать использовать личный токен доступа через HTTPS (рекомендуется) или ключ SSH до 13 августа 2021 года, чтобы избежать сбоев. Если вы получаете предупреждение о том, что используете устаревшую стороннюю интеграцию, вам следует обновить клиент до последней версии.
• Для интеграторов: вы должны аутентифицировать интеграцию с помощью потоков авторизации в Интернете или на устройстве до 13 августа 2021 года, чтобы избежать сбоев.

Дополнительные сведения см. в разделе Авторизация приложений OAuth и объявление в блоге разработчиков.

Включение двухфакторной аутентификации

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

Браунауты

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

График

Сегодня — если вы используете пароли для аутентификации операций Git с GitHub.com сегодня, вы скоро получите электронное письмо с призывом обновить метод аутентификации или сторонний клиент.

• 30 июня и 28 июля 2021 г. — аутентификация с помощью токена (или ключа SSH) будет временно требоваться для всех операций Git, чтобы побудить затронутых клиентов обновить свой метод аутентификации (см. ниже).
• 13 августа 2021 г. — для всех аутентифицированных операций Git потребуется аутентификация с помощью токена (или ключа SSH).

Использование Git

git hist

git status

git add .

git log

git commit -m "Описание изменения"

git push

• This email address is being protected from spambots. You need JavaScript enabled to view it.ya.ru + Token1

Восстановление файла в предыдущее состояние

git log

git checkout <обозначение коммита> <имя файла>

Показать настройки всех уровней

git config --list --global

IgorL@igor2022 MINGW64 ~/PycharmProjects/LawBot (master)
$ git config --list
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=true
core.fscache=true
core.symlinks=false
pull.rebase=false
credential.helper=manager
credential.https://dev.azure.com.usehttppath=true
init.defaultbranch=master
user.name=IgorLytkin
user.email=This email address is being protected from spambots. You need JavaScript enabled to view it.
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
remote.origin.url=https://github.com/IgorLytkin/LawBot.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

Посмотреть все настройки и где они хранятся 

git config --list --show-origin

IgorL@igor2022 MINGW64 ~/PycharmProjects/LawBot (master)
$ git config --list --show-origin
file:C:/Program Files/Git/etc/gitconfig diff.astextplain.textconv=astextplain
file:C:/Program Files/Git/etc/gitconfig filter.lfs.clean=git-lfs clean -- %f
file:C:/Program Files/Git/etc/gitconfig filter.lfs.smudge=git-lfs smudge -- %f
file:C:/Program Files/Git/etc/gitconfig filter.lfs.process=git-lfs filter-process
file:C:/Program Files/Git/etc/gitconfig filter.lfs.required=true
file:C:/Program Files/Git/etc/gitconfig http.sslbackend=openssl
file:C:/Program Files/Git/etc/gitconfig http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
file:C:/Program Files/Git/etc/gitconfig core.autocrlf=true
file:C:/Program Files/Git/etc/gitconfig core.fscache=true
file:C:/Program Files/Git/etc/gitconfig core.symlinks=false
file:C:/Program Files/Git/etc/gitconfig pull.rebase=false
file:C:/Program Files/Git/etc/gitconfig credential.helper=manager
file:C:/Program Files/Git/etc/gitconfig credential.https://dev.azure.com.usehttppath=true
file:C:/Program Files/Git/etc/gitconfig init.defaultbranch=master
file:C:/Users/IgorL/.gitconfig  user.name=IgorLytkin
file:C:/Users/IgorL/.gitconfig  user.email=This email address is being protected from spambots. You need JavaScript enabled to view it.
file:.git/config        core.repositoryformatversion=0
file:.git/config        core.filemode=false
file:.git/config        core.bare=false
file:.git/config        core.logallrefupdates=true
file:.git/config        core.symlinks=false
file:.git/config        core.ignorecase=true
file:.git/config        remote.origin.url=https://github.com/IgorLytkin/LawBot.git
file:.git/config        remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
file:.git/config        branch.master.remote=origin
file:.git/config        branch.master.merge=refs/heads/master

Книги

Head First Git: A Learner's Guide to Understanding Git from the Inside Out (2022). Автор: Raju Gandhi ISBN: 978-1-492-09251-3, 13.01.2022.

Глава 1. Начало Git

mkdir created-using-the-command-line 
cd created-using-the-command-line
git init
git config --global user.name "IgorLytkin"
git config --global user.email "This email address is being protected from spambots. You need JavaScript enabled to view it."
git add Checklist.md
git commit -m "My first commit" 

Состояния файла

UNTRACKED - Git видит новый файл в рабочем каталоге. Это файл, который никогда не добавлялся в индекс. Git помечает этот файл как неотслеживаемый”, и таким образом Git сообщает нам , что вам, вероятно, следует добавить его в индекс (и в конечном итоге зафиксировать).

STAGED - Файл был добавлен в индекс. Если вы впервые добавили этот конкретный файл в индекс, Git начнет отслеживать этот файл. Несмотря на это, добавление файла в индекс помечает его как “STAGED”.

UNMODIFIED - Как только вы фиксируете, он берет все файлы, которые вы добавили в индекс , и фиксирует их в своей памяти. Затем он помечает все эти файлы как “неизмененные”. Это то состояние, к которому вы все должны стремиться. Это говорит вам о том, что содержимое файла надежно сохранено в памяти Git.

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

Историю коммитов Git часто называют ориентированным ациклическим графом, или сокращенно DAG, в котором коммиты образуют “узлы”, а указатели на родительский объект образуют “ребра”. Они являются направленными, потому что дочерние элементы указывают на родительские, и ациклическими , потому что родители не указывают обратно на своих дочерних элементов.

Глава 2. Разветвление (множественные ходы мыслей)

Branch - ветвь.

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

Фиксация (commit) представляет собой момент времени, а ветвь представляет собой серию фиксаций. Напомним, что серия коммитов - это также история коммитов. Таким образом, ветви - это разные истории коммитов, все в одном репозитории! В любой момент вы можете создать новую ветвь, переключаться между ветвями, отказаться от ветки (то есть решить отказаться от всей работы, которую вы в нее вложили) и даже объединить ветви.

git branch my-first-branch 
git branch
git switch my-first-branch  

Каждый раз, когда вы переключаете ветки, Git переписывает ваш рабочий каталог, чтобы он выглядел так, как это было, когда вы делали самую последнюю фиксацию в ветке, на которую вы только что переключились. Ветви ”Feature" часто называют ветвями “topic”. По сути, они одинаковы.

git branch -v 

integration branch - ветвь интеграции, master/main или выбранная.

Глобальные настройки Git git config --global -l

Слияние ветвей Git 

IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)
$ git branch -v
add-fall-menu ad0416a update heading
add-thurs-menu f3ddca3 add thursdays menu
* master f3ddca3 add thursdays menu
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (add-fall-menu)
$ git switch master
Switched to branch 'master'
IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)

$ git merge add-thurs-menu
Updating 620f49f..f3ddca3
Fast-forward
thursdays-menu.md | 10 ++++++++++
1 file changed, 10 insertions(+)
create mode 100644 thursdays-menu.md

IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)
$ ls -la
total 14
drwxr-xr-x 1 IgorL 197121   0 Aug 17 13:57 ./
drwxr-xr-x 1 IgorL 197121   0 Aug 17 13:02 ../
drwxr-xr-x 1 IgorL 197121   0 Aug 17 13:57 .git/
-rw-r--r-- 1 IgorL 197121 425 Aug 17 11:17 menu.md
-rw-r--r-- 1 IgorL 197121 417 Aug 17 13:57 thursdays-menu.md

IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)
$ git merge add-fall-menu
Merge made by the 'ort' strategy.
fall-menu.md | 12 ++++++++++++
1 file changed, 12 insertions(+)
create mode 100644 fall-menu.md

IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/80s-diner (master)
$ ls -la
total 18
drwxr-xr-x 1 IgorL 197121 0 Aug 17 14:31 ./
drwxr-xr-x 1 IgorL 197121 0 Aug 17 13:02 ../
drwxr-xr-x 1 IgorL 197121 0 Aug 17 14:31 .git/
-rw-r--r-- 1 IgorL 197121 570 Aug 17 14:31 fall-menu.md
-rw-r--r-- 1 IgorL 197121 425 Aug 17 11:17 menu.md
-rw-r--r-- 1 IgorL 197121 417 Aug 17 14:31 thursdays-menu.md

После второго git merge (слияние ветви master с ветвью add-fall-menu) в рабочем каталоге появился файл fall-menu.md. Почему не появился после первого git merge?

Конфликты слияния возникают, если две ветви вносят изменения в один файл. Для разрешения конфликта нужно отредактировать конфликтный файл, устранить конфликт, добавить файл и выполнить фиксацию.

Глава 3. Осматриваясь вокруг (исследуя свой репозиторий Git)

git log

$ git log -v
commit 8d670e93e297b126fc0466caf37c0033b6c018ab (HEAD -> spicy-version)
Author: Rosemary Berry <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Mon Mar 15 18:52:50 2021 -0400
update recipe name

commit 4cca5a7b3225a88c2df12bd157f5877bc3dded9e
Author: Rosemary Berry <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Mon Feb 15 17:24:41 2021 -0500
make it spicy

commit 5db2b68c4cf2699e89fe1b526a7e4a171d83b2ef (master)
Author: Rosemary Berry <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Sat Jan 2 19:22:59 2021 -0500

first attempt

IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/chapter03/recipes (spicy-version)
$ git log --abbrev-commit
commit 8d670e9 (HEAD -> spicy-version)
Author: Rosemary Berry <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Mon Mar 15 18:52:50 2021 -0400
update recipe name

commit 4cca5a7
Author: Rosemary Berry <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Mon Feb 15 17:24:41 2021 -0500
make it spicy

commit 5db2b68 (master)
Author: Rosemary Berry <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Date: Sat Jan 2 19:22:59 2021 -0500

first attempt

IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/chapter03/recipes (spicy-version)
$ git log --pretty=oneline
8d670e93e297b126fc0466caf37c0033b6c018ab (HEAD -> spicy-version) update recipe name
4cca5a7b3225a88c2df12bd157f5877bc3dded9e make it spicy
5db2b68c4cf2699e89fe1b526a7e4a171d83b2ef (master) first attempt

IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/chapter03/recipes (spicy-version)
$ git log --pretty=oneline --abbrev-commit
8d670e9 (HEAD -> spicy-version) update recipe name
4cca5a7 make it spicy
5db2b68 (master) first attempt

Отображение полного графа всех ветвей в репозитории:

IgorL@igor2022 MINGW64 /d/Git/headfirst-git-samples/chapter03/recipes (master)
$ git log --oneline --all --graph
* 8d670e9 (spicy-version) update recipe name
* 4cca5a7 make it spicy
| * 0065b8a (different-base) cut down salt
| * 549e0da use sour cream
|/
* 5db2b68 (HEAD -> master) first attempt

Глава 4. Отмена (исправление ошибок)

git restore 
git restore --staged
git rm
git mv