Как сбросить git bash на windows

1. Файл [path]/etc/gitconfig содержит значения, общие для всех пользователей системы и для всех их репозиториев.
   Если при запуске git config указать параметр --system, то параметры будут читаться и сохраняться именно в этот файл.
   Так как этот файл является системным, то вам потребуются права суперпользователя для внесения изменений в него.

2. Файл ~/.gitconfig или ~/.config/git/config хранит настройки конкретного пользователя.
   Этот файл используется при указании параметра --global и применяется ко всем репозиториям, с которыми вы работаете в текущей системе.

3. Файл config в каталоге Git (т. е. .git/config) репозитория, который вы используете в данный момент, хранит настройки конкретного репозитория.
   Вы можете заставить Git читать и писать в этот файл с помощью параметра --local, но на самом деле это значение по умолчанию.
   Неудивительно, что вам нужно находиться где-то в репозитории Git, чтобы эта опция работала правильно.

$ git config --list --show-origin

Имя пользователя

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

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

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

Многие GUI-инструменты предлагают сделать это при первом запуске.

Выбор редактора

Теперь, когда вы указали своё имя, самое время выбрать текстовый редактор, который будет использоваться, если будет нужно набрать сообщение в Git.
По умолчанию Git использует стандартный редактор вашей системы, которым обычно является Vim.
Если вы хотите использовать другой текстовый редактор, например, Emacs, можно проделать следующее:

$ git config --global core.editor emacs

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

В случае с Notepad++, популярным редактором, скорее всего вы захотите установить 32-битную версию, так как 64-битная версия ещё не поддерживает все плагины.
Если у вас 32-битная Windows или 64-битный редактор с 64-битной системой, то выполните следующее:

$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"

Настройка ветки по умолчанию

Когда вы инициализируете репозиторий командой git init, Git создаёт ветку с именем master по умолчанию.
Начиная с версии 2.28, вы можете задать другое имя для создания ветки по умолчанию.

Например, чтобы установить имя main для вашей ветки по умолчанию, выполните следующую команду:

$ git config --global init.defaultBranch main

Проверка настроек

Если вы хотите проверить используемую конфигурацию, можете использовать команду git config --list, чтобы показать все настройки, которые Git найдёт:

$ git config --list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

Некоторые ключи (названия) настроек могут отображаться несколько раз, потому что Git читает настройки из разных файлов (например, из /etc/gitconfig и ~/.gitconfig).
В таком случае Git использует последнее значение для каждого ключа.

Также вы можете проверить значение конкретного ключа, выполнив git config <key>:

$ git config user.name
John Doe

$ git config --show-origin rerere.autoUpdate
file:/home/johndoe/.gitconfig	false

16

14

$ git config credential.helper store

5

$ git config --system --list

credential.helper=manager

7

git credential-manager

git credential-manager uninstall

8

git config --system -l

credential.helper=!github --credentials

git config --system --unset credential.helper

3

git config --list

git config credential.helper ""

6

2

2

2

1

git config --list

git config --system --unset credential.helper

1

2

git credential-cache exit

5

1

0

0

git config --global credential.helper wincred

1

[credential]
helper = !"C:/Program Files (x86)/GitExtensions/GitCredentialWinStore/git-credential-winstore.exe"

0

git remote show origin

4

$ git remote -v 
origin  https://bitbucket.org/org/~username/your-project.git (fetch)
origin  https://bitbucket.org/org/~username/your-project.git (push)

$ git remote remove origin

$ git remote add origin https://bitbucket.org/org/~username/your-project.git

2

0

rm -rf ~/.git-credentials

1

2

c:users[username].git-credentials

2

16

14

$ git config credential.helper store

5

$ git config --system --list

credential.helper=manager

7

git credential-manager

git credential-manager uninstall

8

git config --system -l

credential.helper=!github --credentials

git config --system --unset credential.helper

3

git config --list

git config credential.helper ""

6

2

2

2

1

git config --list

git config --system --unset credential.helper

1

2

git credential-cache exit

5

1

0

0

git config --global credential.helper wincred

1

[credential]
helper = !"C:/Program Files (x86)/GitExtensions/GitCredentialWinStore/git-credential-winstore.exe"

0

git remote show origin

4

$ git remote -v 
origin  https://bitbucket.org/org/~username/your-project.git (fetch)
origin  https://bitbucket.org/org/~username/your-project.git (push)

$ git remote remove origin

$ git remote add origin https://bitbucket.org/org/~username/your-project.git

2

0

rm -rf ~/.git-credentials

1

2

c:users[username].git-credentials

2

$ mkdir git_reset_test
$ cd git_reset_test/
$ git init .
Initialized empty Git repository in /git_reset_test/.git/
$ touch reset_lifecycle_file
$ git add reset_lifecycle_file
$ git commit -m"initial commit"
[main (root-commit) d386d86] initial commit
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 reset_lifecycle_file

$ echo 'hello git reset' > reset_lifecycle_file
 $ git status 
 On branch main
 Changes not staged for commit: 
 (use "git add ..." to update what will be committed) 
 (use "git checkout -- ..." to discard changes in working directory) 
 modified: reset_lifecycle_file

git ls-files -s
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0   reset_lifecycle_file

$ git add reset_lifecycle_file 
 
$ git status 
 
On branch main Changes to be committed: 
 
(use "git reset HEAD ..." to unstage) 
 
modified: reset_lifecycle_file

$ git commit -am"update content of reset_lifecycle_file"
[main dc67808] update content of reset_lifecycle_file
1 file changed, 1 insertion(+)
$ git status
On branch main
nothing to commit, working tree clean

$ echo 'new file content' > new_file
$ git add new_file
$ echo 'changed content' >> reset_lifecycle_file

$ git status
On branch main
Changes to be committed:
   (use "git reset HEAD ..." to unstage)
new file: new_file
Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git checkout -- ..." to discard changes in working directory)
modified: reset_lifecycle_file

$ git ls-files -s
100644 8e66654a5477b1bf4765946147c49509a431f963 0 new_file
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file

$ git reset --hard
HEAD is now at dc67808 update content of reset_lifecycle_file
$ git status
On branch main
nothing to commit, working tree clean
$ git ls-files -s
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file

$ echo 'new file content' > new_file
$ git add new_file
$ echo 'append content' >> reset_lifecycle_file
$ git add reset_lifecycle_file
$ git status
On branch main
Changes to be committed:
    (use "git reset HEAD ..." to unstage)
new file: new_file
modified: reset_lifecycle_file
$ git ls-files -s
100644 8e66654a5477b1bf4765946147c49509a431f963 0 new_file
100644 7ab362db063f9e9426901092c00a3394b4bec53d 0 reset_lifecycle_file

$ git reset --mixed
$ git status
On branch main
Changes not staged for commit:
    (use "git add ..." to update what will be committed)
    (use "git checkout -- ..." to discard changes in working directory)
modified: reset_lifecycle_file
Untracked files:
    (use "git add ..." to include in what will be committed)
new_file
no changes added to commit (use "git add" and/or "git commit -a")
$ git ls-files -s
100644 d7d77c1b04b5edd5acfc85de0b592449e5303770 0 reset_lifecycle_file

$ git add reset_lifecycle_file 
 
$ git ls-files -s 
 
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file 
 
$ git status 
 
On branch main
 
Changes to be committed: 
 
(use "git reset HEAD ..." to unstage) 
 
modified: reset_lifecycle_file 
 
Untracked files: 
 
(use "git add ..." to include in what will be committed) 
 
new_file

$ git reset --soft
$ git status
On branch main
Changes to be committed:
    (use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
$ git ls-files -s
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file

$ git log
commit 62e793f6941c7e0d4ad9a1345a175fe8f45cb9df
Author: bitbucket 
Date: Fri Dec 1 15:03:07 2017 -0800
prepend content to reset_lifecycle_file
commit dc67808a6da9f0dec51ed16d3d8823f28e1a72a
Author: bitbucket 
Date: Fri Dec 1 10:21:57 2017 -0800
update content of reset_lifecycle_file
commit 780411da3b47117270c0e3a8d5dcfd11d28d04a4
Author: bitbucket 
Date: Thu Nov 30 16:50:39 2017 -0800
initial commit

$ git status && git ls-files -s
On branch main
nothing to commit, working tree clean
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file

$git reset --soft 780411da3b47117270c0e3a8d5dcfd11d28d04a4
$ git status && git ls-files -s
On branch main
Changes to be committed:
    (use "git reset HEAD ..." to unstage)
modified: reset_lifecycle_file
100644 67cc52710639e5da6b515416fd779d0741e3762e 0 reset_lifecycle_file

Если git revert — «безопасный» способ отмены изменений, то git reset — опасный. При выполнении команды git reset есть реальный риск потерять наработки. Команда git reset никогда не удаляет коммиты, однако может оставить их без родителя, т. е. указатель потеряет прямой путь для доступа к ним. Такие коммиты без родителя обычно можно найти и восстановить с помощью команды git reflog. После запуска внутреннего «сборщика мусора» Git навсегда удалит все коммиты без родителя. По умолчанию Git запускает «сборщик мусора» каждые 30 дней. История коммитов — одно из «трех деревьев Git»; два других — раздел проиндексированных файлов и рабочий каталог — не отличаются таким же постоянством, как коммиты. При использовании этого инструмента необходимо соблюдать осторожность, поскольку это одна из немногих команд Git, которые могут привести к потере ваших наработок.

Команда revert предназначена для безопасной отмены публичных коммитов, а git reset — для отмены локальных изменений в разделе проиндексированных файлов и рабочем каталоге. Поскольку они предназначены для разных целей, их реализация также различается: команда reset полностью удаляет набор изменений, тогда как команда revert оставляет исходный набор изменений и использует новый коммит для применения отмены.

Как только вы добавите новые коммиты после выполнения команды reset, Git будет считать, что локальная история отклонилась от ветки origin/main, а коммит слияния, необходимый для синхронизации репозиториев, скорее всего, собьет с толку вашу команду и помешает ей.

Команду git reset <коммит> можно использовать только для локальных экспериментов, в которых что-то пошло не так, а не для публичных изменений. Если необходимо исправить публичный коммит, воспользуйтесь специальной командой git revert.

# Edit both hello.py and main.py
# Stage everything in the current directory
git add .
# Realize that the changes in hello.py and main.py
# should be committed in different snapshots
# Unstage main.py
git reset main.py
# Commit only hello.py
git commit -m "Make some changes to hello.py"
# Commit main.py in a separate snapshot
git add main.py
git commit -m "Edit main.py"

# Create a new file called `foo.py` and add some code to it
# Commit it to the project history
git add foo.py
git commit -m "Start developing a crazy feature"
# Edit `foo.py` again and change some other tracked files, too
# Commit another snapshot
git commit -a -m "Continue my crazy feature"
# Decide to scrap the feature and remove the associated commits
git reset --hard HEAD~2

Итак, git reset — это мощная команда, используемая для отмены локальных изменений в репозитории Git. Git reset работает с «тремя деревьями Git»: историей коммитов (HEAD), разделом проиндексированных файлов и рабочим каталогом. Существует три параметра командной строки, соответствующие этим трем деревьям. Эти параметры — --soft, --mixed и --hard — можно передавать команде git reset.

В этой статье мы воспользовались несколькими другими командами Git для демонстрации работы команды reset. Подробнее об этих командах см. на соответствующих страницах: git status, git log, git add, git checkout, git reflog и git revert.

git config --global user.name "Your Name" # указать имя, которым будут подписаны коммиты
git config --global user.email "[email protected]"  # указать электропочту, которая будет в описании коммитера

git config --global core.autocrlf true # включить преобразование окончаний строк из CRLF в LF

# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти
```bash
# Нажатия кнопок
ESC     — переход в командный режим
i       — переход в режим редактирования текста
ZQ (зажат Shift, поочередное нажатие) — выход без сохранения
ZZ (зажат Shift, поочередное нажатие) — сохранить и выйти

# Ввод в командном режиме
:q!             — выйти без сохранения
:wq             — сохранить файл и выйти
:w filename.txt — сохранить файл как filename.txt

git init             # создать новый проект в текущей директории
git init folder-name # создать новый проект в указанной директории

# клонировать удаленный репозиторий в одноименную директорию
git clone https://github.com/cyberspacedk/Git-commands.git    

# клонировать удаленный репозиторий в директорию «FolderName»
git clone https://github.com/cyberspacedk/Git-commands.git FolderName 

# клонировать репозиторий в текущую директорию
git clone https://github.com:nicothin/web-design.git .

git status              # показать состояние репозитория (отслеживаемые, изменённые, новые файлы и пр.)
git diff                # сравнить рабочую директорию и индекс (неотслеживаемые файлы ИГНОРИРУЮТСЯ)
git diff --color-words  # сравнить рабочую директорию и индекс, показать отличия в словах (неотслеживаемые файлы ИГНОРИРУЮТСЯ)
git diff index.html     # сравнить файл из рабочей директории и индекс
git diff HEAD           # сравнить рабочую директорию и коммит, на который указывает HEAD (неотслеживаемые файлы ИГНОРИРУЮТСЯ)
git diff --staged       # сравнить индекс и коммит с HEAD
git diff master feature # посмотреть что сделано в ветке feature по сравнению с веткой master
git diff --name-only master feature # посмотреть что сделано в ветке feature по сравнению с веткой master, показать только имена файлов
git diff master...feature # посмотреть что сделано в ветке feature с момента (коммита) расхождения с master

git add .        # добавить в индекс все новые, изменённые, удалённые файлы из текущей директории и её поддиректорий
git add text.txt # добавить в индекс указанный файл (был изменён, был удалён или это новый файл)
git add -i       # запустить интерактивную оболочку для добавления в индекс только выбранных файлов
git add -p       # показать новые/изменённые файлы по очереди с указанием их изменений и вопросом об отслеживании/индексировании

git reset            # убрать из индекса все добавленные в него изменения (в рабочей директории все изменения сохранятся), антипод git add
git reset readme.txt # убрать из индекса изменения указанного файла (в рабочей директории изменения сохранятся)

git checkout text.txt      # ОПАСНО: отменить изменения в файле, вернуть состояние файла, имеющееся в индексе
git reset --hard           # ОПАСНО: отменить изменения; вернуть то, что в коммите, на который указывает HEAD (незакомиченные изменения удалены из индекса и из рабочей директории, неотслеживаемые файлы останутся на месте)
git clean -df              # удалить неотслеживаемые файлы и директории

git commit -m "Name of commit"    # зафиксировать в коммите проиндексированные изменения (закоммитить), добавить сообщение
git commit -a -m "Name of commit" # проиндексировать отслеживаемые файлы (ТОЛЬКО отслеживаемые, но НЕ новые файлы) и закоммитить, добавить сообщение

git revert HEAD --no-edit    # создать новый коммит, отменяющий изменения последнего коммита без запуска редактора сообщения
git revert b9533bb --no-edit # то же, но отменяются изменения, внесённые коммитом с указанным хешем (b9533bb)

# ВНИМАНИЕ! Опасные команды, можно потерять незакоммиченные изменения
git commit --amend -m "Название"  # «перекоммитить» изменения последнего коммита, заменить его новым коммитом с другим сообщением (сдвинуть текущую ветку на один коммит назад, сохранив рабочую директорию и индекс «как есть», создать новый коммит с данными из «отменяемого» коммита, но новым сообщением)
git reset --hard @~      # передвинуть HEAD (и ветку) на предыдущий коммит, рабочую директорию и индекс сделать такими, какими они были в момент предыдущего коммита
git reset --hard 75e2d51 # передвинуть HEAD (и ветку) на коммит с указанным хешем, рабочую директорию и индекс сделать такими, какими они были в момент указанного коммита
git reset --soft @~      # передвинуть HEAD (и ветку) на предыдущий коммит, но в рабочей директории и индексе оставить все изменения
git reset --soft @~2     # то же, но передвинуть HEAD (и ветку) на 2 коммита назад
git reset @~             # передвинуть HEAD (и ветку) на предыдущий коммит, рабочую директорию оставить как есть, индекс сделать таким, каким он был в момент предыдущего коммита (удобнее, чем git reset --soft @~, если индекс нужно задать заново)
# Почти как git reset --hard, но безопаснее: не получится потерять изменения в рабочей директории
git reset --keep @~      # передвинуть HEAD (и ветку) на предыдущий коммит, сбросить индекс, но в рабочей директории оставить изменения, если возможно (если файл с изменениями между коммитами менялся, будет выдана ошибка и переключение не произойдёт)

git checkout b9533bb # переключиться на коммит с указанным хешем (переместить HEAD на указанный коммит, рабочую директорию вернуть к состоянию, на момент этого коммита)
git checkout master  # переключиться на коммит, на который указывает master (переместить HEAD на коммит, на который указывает master, рабочую директорию вернуть к состоянию на момент этого коммита)

git checkout -b new-branch 5589877   # создать ветку new-branch, начинающуюся с коммита c хешем 5589877 (переместить HEAD на указанный коммит, рабочую директорию вернуть к состоянию, на момент этого коммита, создать указатель на этот коммит (ветку) с указанным именем)

git checkout 5589877 index.html  # восстановить в рабочей директории указанный файл на момент указанного коммита (и добавить это изменение в индекс) (git reset index.html для удаления из индекса, но сохранения изменений в файле)

git cherry-pick 5589877          # скопировать на активную ветку изменения из указанного коммита, закоммитить эти изменения
git cherry-pick master~2..master # скопировать на активную ветку изменения из master (2 последних коммита)
git cherry-pick -n 5589877       # скопировать на активную ветку изменения из указанного коммита, но НЕ КОММИТИТЬ (подразумевается, что мы сами потом закоммитим)
git cherry-pick master..feature  # скопировать на активную ветку изменения из всех коммитов ветки feature с момента её расхождения с master (похоже на слияние веток, но это копирование изменений, а не слияние), закоммитить эти изменения; это может вызвать конфликт
git cherry-pick --abort    # прервать конфликтный перенос коммитов
git cherry-pick --continue # продолжить конфликтный перенос коммитов (сработает только после решения конфликта)

git rm text.txt    # удалить отслеживаемый неизменённый файл и проиндексировать это изменение
git rm -f text.txt # удалить отслеживаемый изменённый файл и проиндексировать это изменение
git rm -r log/     # удалить всё содержимое отслеживаемой директории log/ и проиндексировать это изменение
git rm ind*        # удалить все отслеживаемые файлы с именем, начинающимся на «ind» в текущей директории и проиндексировать это изменение
git rm --cached readme.txt # удалить из отслеживаемых индексированный файл (ФАЙЛ ОСТАНЕТСЯ НА МЕСТЕ) (часто используется для нечаянно добавленных в отслеживаемые файлов)

git mv text.txt test_new.txt # переименовать файл «text.txt» в «test_new.txt» и проиндексировать это изменение
git mv readme_new.md folder/ # переместить файл readme_new.md в директорию folder/ (должна существовать) и проиндексировать это изменение

git log master             # показать коммиты в указанной ветке
git log -2                 # показать последние 2 коммита в активной ветке
git log -2 --stat          # показать последние 2 коммита и статистику внесенных ими изменений
git log -p -22             # показать последние 22 коммита и внесенную ими разницу на уровне строк
git log --graph -10        # показать последние 10 коммитов с ASCII-представлением ветвления
git log --since=2.weeks    # показать коммиты за последние 2 недели
git log --after '2018-06-30' # показать коммиты, сделанные после указанной даты
git log index.html         # показать историю изменений файла index.html (только коммиты)
git log -5 index.html      # показать историю изменений файла index.html, последние 5 коммитов (только коммиты)
git log -p index.html      # показать историю изменений файла index.html (коммиты и изменения)
git log -G'myFunction' -p  # показать все коммиты, в которых менялись строки с myFunction (в кавычках регулярное выражение)
git log -L '/<head>/','/</head>/':index.html # показать изменения от указанного до указанного регулярных выражений в указанном файле
git log --grep fix         # показать коммиты, в описании которых есть буквосочетание fix (регистрозависимо, только коммиты текущей ветки)
git log --grep fix -i      # показать коммиты, в описании которых есть буквосочетание fix (регистроНЕзависимо, только коммиты текущей ветки)
git log --grep 'fix(ing|me)' -P # показать коммиты, в описании которых есть совпадения для регулярного выражения (только коммиты текущей ветки)
git log --pretty=format:"%h - %an, %ar : %s" -4 # показать последние 4 коммита с форматированием выводимых данных
git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short # мой формат вывода, висящий на алиасе оболочки
git log master..branch_99  # показать коммиты из ветки branch_99, которые не влиты в master
git log branch_99..master  # показать коммиты из ветки master, которые не влиты в branch_99
git log master...branch_99 --boundary -- graph # показать коммиты из указанных веток, начиная с их расхождения (коммит расхождения будет показан)

git show 60d6582           # показать изменения из коммита с указанным хешем
git show HEAD~             # показать данные о предыдущем коммите в активной ветке
git show @~                # аналогично предыдущему
git show HEAD~3            # показать данные о коммите, который был 3 коммита назад
git show my_branch~2       # показать данные о коммите, который был 2 коммита назад в указанной ветке
git show @~:index.html     # показать контент указанного файла на момент предыдущего (от HEAD) коммита
git show :/"подвал"        # показать самый новый коммит, в описании которого есть указанное слово (из любой ветки)

git blame README.md --date=short -L 5,8 # показать строки 5-8 указанного файла и коммиты, в которых строки были добавлены

git reflog -20             # показать последние 20 изменений положения указателя HEAD
git reflog --format='%C(auto)%h %<|(20)%gd %C(blue)%cr%C(reset) %gs (%s)' -20 # то же, но с указанием давности действий

git branch                 # показать список веток
git branch -v              # показать список веток и последний коммит в каждой
git branch new_branch      # создать новую ветку с указанным именем на текущем коммите
git branch new_branch 5589877 # создать новую ветку с указанным именем на указанном коммите
git branch -f master 5589877  # переместить ветку master на указанный коммит
git branch -f master master~2 # переместить ветку master на 2 коммита назад
git checkout new_branch    # перейти в указанную ветку
git checkout -b new_branch # создать новую ветку с указанным именем и перейти в неё
git checkout -B master 5589877 # переместить ветку с указанным именем на указанный коммит и перейти в неё
git merge hotfix           # влить в ветку, в которой находимся, данные из ветки hotfix
git merge hotfix -m "Горячая правка" # влить в ветку, в которой находимся, данные из ветки hotfix (указано сообщение коммита слияния)
git merge hotfix --log     # влить в ветку, в которой находимся, данные из ветки hotfix, показать редактор описания коммита, добавить в него сообщения вливаемых коммитов
git merge hotfix --no-ff   # влить в ветку, в которой находимся, данные из ветки hotfix, запретить простой сдвиг указателя, изменения из hotfix «останутся» в ней, а в активной ветке появится только коммит слияния
git branch -d hotfix       # удалить ветку hotfix (используется, если её изменения уже влиты в главную ветку)
git branch --merged        # показать ветки, уже слитые с активной
git branch --no-merged     # показать ветки, не слитые с активной
git branch -a              # показать все имеющиеся ветки (в т.ч. на удаленных репозиториях)
git branch -m old_branch_name new_branch_name # переименовать локально ветку old_branch_name в new_branch_name
git branch -m new_branch_name # переименовать локально ТЕКУЩУЮ ветку в new_branch_name
git push origin :old_branch_name new_branch_name # применить переименование в удаленном репозитории
git branch --unset-upstream # завершить процесс переименования

git tag v1.0.0               # создать тег с указанным именем на коммите, на который указывает HEAD
git tag -a -m 'В продакшен!' v1.0.1 master # создать тег с описанием на том коммите, на который смотрит ветка master
git tag -d v1.0.0            # удалить тег с указанным именем(ами)
git tag -n                   # показать все теги, и по 1 строке сообщения коммитов, на которые они указывают
git tag -n -l 'v1.*'         # показать все теги, которые начинаются с 'v1.*'

git stash     # временно сохранить незакоммиченные изменения и убрать их из рабочей директории
git stash pop # вернуть сохраненные командой git stash изменения в рабочую директорию

git remote -v              # показать список удалённых репозиториев, связанных с локальным
git remote remove origin   # убрать привязку удалённого репозитория с сокр. именем origin
git remote add origin https://github.com:nicothin/test.git # добавить удалённый репозиторий (с сокр. именем origin) с указанным URL
git remote rm origin       # удалить привязку удалённого репозитория
git remote show origin     # получить данные об удалённом репозитории с сокращенным именем origin
git fetch origin           # скачать все ветки с удаленного репозитория (с сокр. именем origin), но не сливать со своими ветками
git fetch origin master    # то же, но скачивается только указанная ветка
git checkout --track origin/github_branch # создать локальную ветку github_branch (данные взять из удалённого репозитория с сокр. именем origin, ветка github_branch) и переключиться на неё
git push origin master     # отправить в удалённый репозиторий (с сокр. именем origin) данные своей ветки master
git pull origin            # влить изменения с удалённого репозитория (все ветки)
git pull origin master     # влить изменения с удалённого репозитория (только указанная ветка)

git merge feature                # влить в активную ветку изменения из ветки feature
git merge-base master feature    # показать хеш последнего общего коммита для двух указанных веток
git checkout --ours index.html   # оставить в конфликтном файле (index.html) состояние ветки, В КОТОРУЮ мы вливаем (в примере — из ветки master)
git checkout --theirs index.html # оставить в конфликтном файле (index.html) состояние ветки, ИЗ КОТОРОЙ мы вливаем (в примере — из ветки feature)
git checkout --merge index.html  # показать в конфликтном файле (index.html) сравнение содержимого сливаемых веток (для ручного редактирования)
git checkout --conflict=diff3  --merge index.html # показать в конфликтном файле (index.html) сравнение содержимого сливаемых веток плюс то, что было в месте конфликта в коммите, на котором разошлись сливаемые ветки

git reset --hard  # прекратить это прерванное слияние, вернуть рабочую директорию и индекс как было в момент коммита, на который указывает HEAD, а я пойду немного поплачу
git reset --merge # прекратить это прерванное слияние, но оставить изменения, не закоммиченные до слияния (для случая, когда слияние делается не на чистом статусе)
git reset --abort # то же, что и строкой выше

git rebase master # перенести все коммиты (создать их копии) активной ветки так, будто активная ветка ответвилась от master на нынешней вершине master (часто вызывает конфликты)
git rebase --onto master feature # перенести коммиты активной ветки на master, начиная с того места, в котором активная ветка отделилась от ветки feature
git rebase --abort # прервать конфликтный rebase, вернуть рабочую директорию и индекс к состоянию до начала rebase
git rebase --continue # продолжить конфликтный rebase (сработает только после разрешения конфликта и индексации такого разрешения)

git reflog feature -2        # смотрим лог перемещений ветки, которой делали rebase (в этом примере — feature), видим последний коммит ПЕРЕД rebase, на него и нужно перенести указатель ветки
git reset --hard [email protected]{1} # переместить указатель ветки feature на один коммит назад, обновить рабочую директорию и индекс

git archive -o ./project.zip HEAD # создать архив с файловой структурой проекта по указанному пути (состояние репозитория, соответствующее указателю HEAD)

# указана последовательность действий:
# создана директория проекта, мы в ней
git init                      # создаём репозиторий в этой директории
touch readme.md               # создаем файл readme.md
git add readme.md             # добавляем файл в индекс
git commit -m "Старт"         # создаем коммит
git remote add origin https://github.com:nicothin/test.git # добавляем предварительно созданный пустой удаленный репозиторий
git push -u origin master     # отправляем данные из локального репозитория в удаленный (в ветку master)

# указана последовательность действий:
subl inc/header.html          # редактируем и сохраняем разметку «шапки»
git add inc/header.html       # индексируем измененный файл
git commit -m "Убрал телефон из шапки" # делаем коммит
# ВНИМАНИЕ: коммит пока не был отправлен в удалённый репозиторий
# сознаём, что нужно было еще что-то сделать в этом коммите.
subl inc/header.html          # вносим изменения
git add inc/header.html       # индексируем измененный файл (можно git add .)
git commit --amend -m "«Шапка»: выполнена задача №34" # заново делаем коммит

# указана последовательность действий:
git checkout -b new-page-header # создадим новую ветку для задачи изменения «шапки» и перейдём в неё
subl inc/header.html            # редактируем разметку «шапки»
git commit -a -m "Новая шапка: смена логотипа" # делаем коммит (работа еще не завершена)
# тут выясняется, что есть баг с контактом в «подвале»
git checkout master             # возвращаемся к ветке master
subl inc/footer.html            # устраняем баг и сохраняем разметку «подвала»
git commit -a -m "Исправление контакта в подвале" # делаем коммит
git push                        # отправляем коммит с быстрым критическим изменением в master в удалённом репозитории
git checkout new-page-header    # переключаемся обратно в ветку new-page-header для продолжения работ над «шапкой»
subl inc/header.html            # редактируем и сохраняем разметку «шапки»
git commit -a -m "Новая шапка: смена навигации" # делаем коммит (работа над «шапкой» завершена)
git checkout master             # переключаемся в ветку master
git merge new-page-header       # вливаем в master изменения из ветки new-page-header
git branch -d new-page-header   # удаляем ветку new_page_header

# находимся в ветке fix, баг уже «исправлен»
git checkout master            # переключаемся на master
git merge fix                  # вливаем изменения из fix в master
# видим проблему: часть функциональности сломалась
git checkout fix               # переключаемся на fix (пока мы в master, git не даст ее двигать)
git branch -f master ORIG_HEAD # передвигаем ветку master на коммит, указанный в ORIG_HEAD (тот, на который указывала master до вливания fix)

# указана последовательность действий:
git checkout master           # переключаемся на ветку master
git checkout -b branch-1      # создаём ветку branch-1, основанную на ветке master
subl .                        # редактируем и сохраняем файлы
git commit -a -m "Правка 1"   # коммитим
git checkout master           # возвращаемся к ветке master
git checkout -b branch-2      # создаём ветку branch-2, основанную на ветке master
subl .                        # редактируем и сохраняем файлы
git commit -a -m "Правка 2"   # коммитим
git checkout master           # возвращаемся к ветке master
git merge branch-1            # вливаем изменения из ветки branch-1 в текущую ветку (master), удача (автослияние)
git merge branch-2            # вливаем изменения из ветки branch-2 в текущую ветку (master), КОНФЛИКТ автослияния
# Automatic merge failed; fix conflicts and then commit the result.
subl .                        # выбираем в конфликтных файлах те участки, которые нужно оставить, сохраняем
git commit -a -m "Устранение конфликта" # коммитим результат устранения конфликта

# указана последовательность действий:
git remote add upstream https://github.com:address.git # добавляем удаленный репозиторий: сокр. имя — upstream, URL мастер-репозитория
git fetch upstream            # стягиваем все ветки мастер-репозитория, но пока не сливаем со своими
git checkout master           # переключаемся на ветку master своего репозитория
git merge upstream/master     # вливаем стянутую ветку master удалённого репозитория upstream в свою ветку master

# указана последовательность действий:
# сделали изменения, проиндексировали их, закоммитили в master, но ЕЩЁ НЕ ОТПРАВИЛИ (не делали git push)
git checkout -b new-branch    # создаём новую вертку из master
git checkout master           # переключаемся на master
git reset HEAD~ --hard        # сдвигаем указатель (ветку) master на 1 коммит назад
git checkout new-branch       # переключаемся обратно на новую ветку для продолжения работы

# указана последовательность действий:
git checkout f26ed88 -- index.html # восстановить в рабочей директории состояние указанного файла на момент указанного коммита, добавить это изменение в индекс
git commit -am "Navigation fixs"   # сделать коммит

* text=auto

*.html diff=html
*.css  diff=css
*.scss diff=css

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

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

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

Оглавление

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

Сегодня мы познакомимся с командами, которые позволят удалять и восстанавливать файлы в рабочей копии и индексе, отменять изменения на уровне целых коммитов, возвращаться в прошлое нашего репозитория и манипулировать указателем 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, но и их консольный вывод, а также даем комментарии к каждой команде.

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

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