Fetch head что это

web-steel / Шпаргалка GIT

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

HEAD — это символическое имя текущего выбранного коммита — это, по сути, тот коммит, над которым мы в данным момент работаем.

^ — перемещение на один коммит назад

~[num] — перемещение на [num] коммит назад

Комманды:

git —version — Узнать версию git

git config —global user.name «Mark Sicin» — Устанавить имя пользователя

git config —global user.email sicin.mark@example.com — Установить почту пользователя

git init — Создать пустой репозиторий

git init -b [branch] — Создать пустой репозиторий с начальной веткой [branch]

git clone https:// | git clone git:// — Клонировать существующий репозиторий

git add text.txt — Добавить файл в репозиторий

git rm text.txt — Удалить файл

git status — Информация о состояние файлов (изменения, неразрешенные конфликты и тд)

git status -s — Информация о состоянии файлов в коротком формате

git log —oneline — Посмотреть все коммиты в формате одной строки

git log —graph — Посмотеть все коммиты в формате графа

git commit -a -m «Commit text» — Сделать коммит с комментарием

git commit —amend — Изменить комментарий коммита с помощью текстового редактора.

git commit —amend -m «an updated commit message» — Закоммитеть новый комментарий, не открывая текстовый редактор.

git commit —amend —no-edit — Внести изменения в коммит без изменения комментария к нему

git branch [branch] — Создать новую ветку

git branch -f [branch] HEAD~[num] — Переместить ветку [branch] на [num] коммитов назад, относительно текущего выбранного коммита

git branch -f [branch] HEAD^ — Переместить ветку [branch] на один коммитов назад, относительно текущего выбранного коммита

git branch -f [branch] [branch1]^ — Переместить ветку [branch] на один коммитов назад, относительно ветки [branch1]

git branch -u [remote_branch] — Указать текущей ветке отслеживать удалённую ветку [remote_branch]

git checkout [branch] — Переключиться на ветку [branch] (HEAD указывает на коммит, на который указывает [branch])

git checkout [commit] — Переключиться на определенный коммит (HEAD указывает на выбранный коммит)

git checkout -b [branch] — Создать ветку указывающую на текущем коммите и переключиться на нее

git checkout -b [branch1] [branch2] — Создать ветку [branch1] указывающую на ветку [branch2] и переключиться на нее

git checkout [branch]^ — Переключиться на один коммит назад, относительно коммита на который указывает [branch]

git checkout [branch]~[num] — Переключиться на [num] коммитов назад, относительно коммита на который указывает [branch]

git checkout HEAD^ — Переключиться на один коммит назад, относительно текущего выбраного коммита

git checkout HEAD~[num] — Переключиться на [num] коммитов назад, относительно текущего выбраного коммита

git merge [branch] — Смерждить ветку [branch] c текущей

git rebase [branch] — Копирует набор коммитов из текущей ветки и переносит их в [branch].

git rebase [branch] [branch1] — Копирует коммиты из ветки [branch1] в ветку [branch].

Отличия rebase и merge в том, что c его помощью можно делать чистые и красивые линейные последовательности коммитов. История коммитов будет чище

git rebase -i [branch] — Интерактивный rebase. Git откроет интерфейс просмотра того, какие коммиты готовы к копированию. Также показываются хеши коммитов и комментарии к ним, так что можно легко понять что к чему.

После открытия окна интерактивного rebase есть три варианта для каждого коммита:

— Можно сменить положение коммита по порядку, переставив строчку с ним в редакторе

— Можно «выкинуть» коммит из ребейза.

— Наконец, можно соединить коммиты. При помощи этой функции можно объединять изменения двух коммитов.

git cherry-pick [commit1] [commit2] [. ] — Копирование нескольких коммитов на место, где сейчас находишься (HEAD)

git reset HEAD^ — Отменяет изменения, перенося ссылку на один коммит назад (удаляет все ненужные коммиты)

git reset [branch]~[num] — Отменяет изменения, перенося ссылку на [num] коммитов назад (удаляет все ненужные коммиты)

git reset —soft [commit] — Отменяет изменения, оставляя все измененные файлы (удаляет все ненужные коммиты)

git reset —hard [commit] — Отменяет изменения, удаляя все измененные файлы (удаляет все ненужные коммиты)

git revert [branch] | [commit] | HEAD — Создается новый коммит. Новый коммит содержит изменения, полностью противоположные тем, что сделаны в коммите ([branch] | [commit] | HEAD). Коммит ([branch] | [commit] | HEAD), который мы хотим отменить останется в дереве коммитов для истории, но все действия, которые были в нем сделаны, будут отменены новосозданым коммитом.

git tag [tag] | [branch] | [commit] — Создать постоянный тег, который ссылается на конкретный коммит. Теги являются прекрасными ориентирами в истории изменений

git fetch — Забирает все-все данные из всех веток в ваш локальный репозиторий, но не мерджит их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент

git fetch origin [remote_branch] — Забирает данные из ветки [remote_branch] удаленного репозитория

git fetch origin [remote_branch]:[branch] — Забрать данные из ветки [remote_branch] удаленного репозитория и помещает в ветку [branch] в вашем локальном репозитории

git fetch origin :[branch] — Создает ветку [branch] в локальном репозитории

git pull — Забирает данные в ваш локальный репозиторий и мерджит с вашими наработками

git pull —rebase — Забирает данные в ваш локальный репозиторий и ребейзит комиты

git pull origin [remote_branch] — Забирает данные из ветки [remote_branch] удаленного репозитория и мерджит эти данные с текущей веткой

git pull origin [remote_branch]:[branch] — Забирает данные из ветки [remote_branch] удаленного репозитория, помещает данные в [branch] (если не существует git создает) локального репозитория и мерджит данные с текущей веткой

git push origin — Загрузка ваших изменений в указанный удалённый репозиторий

git push -u origin [branch] — Загрузка данных, с связыванием текущей ветки с веткой [branch] в удаленном репозитории. Если [branch] не существует, git ее создаст

git push origin [branch]:[remote_branch] — Запушить коммиты из ветки [branch] в ветку [remote_branch] на удаленном репохитории, если ветка [remote_branch] не существует, git ее создаст

git push origin :[remote_branch] — Удаляет ветку [remote_branch] из удаленного репозитория

git push origin +[remove_branch] — Принудительно отправить изменения в ветку [remote_branch] удаленного репозитория. Безопаснее использовать +[remote_branch], чем git push -f

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

HEAD

HTTP-метод HEAD запрашивает заголовки, идентичные тем, что возвращаются, если указанный ресурс будет запрошен с помощью HTTP-метода GET . Такой запрос может быть выполнен перед загрузкой большого ресурса, например, для экономии пропускной способности.

Ответ на метод HEAD не должен содержать тело. Если это не так, то его следует игнорировать. Но даже в этом случае заголовки сущности, описывающие содержимое тела, например Content-Length , должны быть включены в ответ. Они не относятся к телу ответа на запрос HEAD , которое должно быть пустым, они относятся к телу ответа, полученный на аналогичный запрос с помощью метода GET .

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

Запрос имеет тело	Нет
Успешный ответ имеет тело	Нет
Безопасный	Да
Идемпотентный	Да
Кешируемый	Да
Допускается в HTML-формах	Нет

Синтаксис

HEAD /index.html

Спецификация

Specification
HTTP Semantics # HEAD

Совместимость с браузерами

BCD tables only load in the browser

Смотрите также

Found a content problem with this page?

• Edit the page on GitHub.
• Report the content issue.
• View the source on GitHub.

This page was last modified on 7 авг. 2023 г. by MDN contributors.

Your blueprint for a better internet.

MDN

Support

• Product help
• Report an issue

Our communities

Developers

• Web Technologies
• Learn Web Development
• MDN Plus
• Hacks Blog

• Website Privacy Notice
• Cookies
• Legal
• Community Participation Guidelines

Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998– 2024 by individual mozilla.org contributors. Content available under a Creative Commons license.

Что означает FETCH_HEAD в Git?

FETCH_HEAD — это краткосрочный рефлекс, чтобы отслеживать то, что только что было получено из удаленного репозитория. git pull сначала вызывает git fetch , в обычных случаях получая ветку из удаленного репозитория; FETCH_HEAD указывает на вершину этой ветки (он хранит SHA1 коммита, как и ветки). git pull затем вызывает git merge , объединяя FETCH_HEAD в текущую ветку. Результат именно тот, что вы ожидаете: коммит в вершине соответствующей удаленной ветки будет объединен в коммит в вершине вашей текущей ветки. Это немного похоже на выполнение git fetch без аргументов (или git remote update ), обновление всех ваших удаленных веток, затем выполнение git merge origin/ , но использование FETCH_HEAD внутри вместо ссылки на любой полученный один ссылку, вместо необходимости называть вещи.

Поделиться 11 февраля 2012 в 03:11

FETCH_HEAD — это ссылка на подсказку последнего fetch, независимо от того, был ли этот fetch инициирован напрямую с помощью команды fetch или в рамках pull. Текущее значение FETCH_HEAD хранится в папке .git в файле с именем, который вы догадались, FETCH_HEAD . Таким образом, если я выдаю:

git fetch https://github.com/ryanmaxwell/Fragaria 

FETCH_HEAD может содержать

3cfda7cfdcf9fb78b44d991f8470df56723658d3 https://github.com/ryanmaxwell/Fragaria 

Если у меня настроен удаленный репозиторий как удаленная ветка отслеживания, то я могу следить за моим fetch слиянием ветки отслеживания. Если я не могу объединить подсказку последнего fetch напрямую с помощью FETCH_HEAD.

git merge FETCH_HEAD 

Поделиться 10 декабря 2012 в 11:37

Как упоминалось в ответе Джонатана, FETCH_HEAD соответствует файлу .git/FETCH_HEAD . Обычно файл будет выглядеть так:

71f026561ddb57063681109aadd0de5bac26ada9 branch 'some-branch' of 669980e32769626587c5f3c45334fb81e5f44c34 not-for-merge branch 'some-other-branch' of b858c89278ab1469c71340eef8cf38cc4ef03fed not-for-merge branch 'yet-some-other-branch' of

Обратите внимание, что все ветки, кроме одной, помечены как not-for-merge . Нечетная из них — это ветка, которая была отмечена до получения. Вкратце: FETCH_HEAD по сути соответствует удаленной версии ветки, которая в данный момент отмечена.

Поделиться 07 августа 2017 в 09:36

Я только что открыл и использовал FETCH_HEAD . Я хотел получить локальную копию какого-то программного обеспечения с сервера, и я сделал

git fetch gitserver release_1 

gitserver — это имя моей машины, которая хранит репозитории git. release_1 — это тег для версии программного обеспечения. К моему удивлению, release_1 не был найден на моей локальной машине. Мне пришлось вводить

 git tag release_1 FETCH_HEAD 

для завершения копирования цепочки коммитов с метками (release_1) из удаленного репозитория в локальный. Fetch нашел удаленный тег, скопировал коммит на мой локальный компьютер, не создал локальный тег, но установил FETCH_HEAD в значение коммита, чтобы я мог найти и использовать его. Затем я использовал FETCH_HEAD для создания локального тега, который соответствует тегу на удаленном репозитории. Это практическая иллюстрация того, что такое FETCH_HEAD и как его можно использовать, и может быть полезно кому-то еще задать вопрос, почему git fetch не делает то, что вы наивно ожидаете. На мой взгляд, лучше всего избегать этого для этой цели, и лучший способ достичь того, что я пытался сделать, это

git fetch gitserver release_1:release_1 

т.е. получить release_1 и вызвать его локально в release_1. (Это source:dest, см. https://git-scm.com/book/en/v2/Git-Internals-The-Refspec; на всякий случай, если вы хотите дать ему другое имя!) Возможно, вам захочется использовать FETCH_HEAD иногда: —

git fetch gitserver bugfix1234 git cherry-pick FETCH_HEAD 

может быть хорошим способом использовать исправление ошибки с номером 1234 на вашем сервере Git и оставить сборку мусора Git для удаления копии с сервера, как только исправление будет выбрано в вашу текущую ветку. (Я предполагаю, что есть хороший чистый коммит с тегами, содержащий все исправления ошибки на сервере!)

Поделиться 08 сентября 2014 в 09:30

FETCH_HEAD — это краткосрочный ссылка, чтобы отслеживать то, что только что было получено из удаленного репозитория.

На самом деле. не всегда учитывая это, с Git 2.29 (Q4 2020), » git fetch » (man ) выучил —no-write-fetch-head вариант, чтобы избежать записи файла FETCH_HEAD . См. коммит 887952b (18 августа 2020) от Джунио С Хамано ( gitster ).
(Слияно Джунио С Хамано — gitster — в коммите b556050 , 24 августа 2020)

fetch : необязательно разрешить отключение обновления FETCH_HEAD

Отключено: Derrick Stolee

• По умолчанию нужно написать FETCH_HEAD, , и опция в основном предназначена для использования с префиксом » —no- «, чтобы переопределить эту настройку по умолчанию, потому что нет соответствующей fetch.writeFetchHEAD переменной конфигурации, чтобы перевернуть ее на отключение (в этом случае может потребоваться положительная форма, чтобы победить ее).

fetch-options теперь включается в его страницу man:

—[no-]write-fetch-head

Напишите список удаленных ссылок, полученных в файле FETCH_HEAD непосредственно в $GIT_DIR .
Это по умолчанию.

Прохождение —no-write-fetch-head из командной строки говорит Git не писать файл.
В опции —dry-run файл никогда не записывается.

Учитывайте также, что с Git 2.29 (Q4 2020), FETCH_HEAD теперь всегда читается из файловой системы независимо от используемого бэкэнда, так как его формат намного богаче обычных ссылок и написан непосредственно с помощью » git fetch » (man ) как обычный файл..

refs : прочтите FETCH_HEAD и MERGE_HEAD в общем виде

Подписано: Хан-Вен Ниньхуа

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

Чтобы сопоставить их с альтернативными бэкэндами ссылки, прочитайте их из файла в общем виде в refs_read_raw_ref() .

С Git 2.29 (Q4 2020), обновления кода получения по запросу в лениво клонированных репозиториях.

fetch : отсутствие отображения FETCH_HEAD , если —no-write-fetch-head

Подписано: Джонатан Тан

887952b8c6 (» fetch : необязательно разрешить отключение обновления FETCH_HEAD «,2020-08-18, Git v2.29.0 — слияние , перечисленное в партии #10 ), ввело возможность отключить запись в FETCH_HEAD во время получения, но не подавляло сообщение » -> FETCH_HEAD» при использовании этой возможности.

Это сообщение вводит в заблуждение в этом случае, потому что FETCH_HEAD не записывается.

Также, поскольку » fetch » используется для ленивого получения отсутствующих объектов в частичном клоне, это значительно увеличивает вывод в этом случае, так как объекты, которые нужно получить, могут быть многочисленными.

Поэтому подавляйте это сообщение при передаче —no-write-fetch-head (но не при установке —dry-run ).

С Git2.41 (Q2 2023), эта опция правильно распространена:

fetch : передать —no-write-fetch-head в подпроцессы

Подписано от: Эрика Вонга

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

Поделиться 31 августа 2020 в 16:06

git pull — это комбинация fetch, за которой следует слияние. Когда происходит git fetch, он отмечает заголовочный коммит того, что он получил в FETCH_HEAD (просто файл с таким именем в.git), и эти коммиты затем объединяются в ваш рабочий каталог.

Поделиться 11 февраля 2012 в 02:45

Позвольте мне внести вклад в это, если это возможно.

1. На изображении я попросил REMOTE, если есть какие-то изменения в BRANCH, на котором я работаю. FETCH сказал мне * branch back_end -> FETCH_HEAD
2. Затем я попросил PULL, пытаясь привести все новые на REMOTE (GITHUB) в мою локальную ветку (она имеет то же имя back_end)

GIT сказал мне—>> FETCH_HEAD, что означает, что все уже было обновлено и что-то нужно обновить из REMOTE BRANCH, ту же информацию, которую мне ранее рассказала инструкция FETCH.

Поделиться 06 июня 2022 в 18:03

Я просто пытался вытянуть ветку (patch), которую я создал, внеся изменения непосредственно с GitHub. Ветка появилась только на GH. Когда я попытался сделать g pull, ветка не появилась.

Я смог проверить ветку, используя:

git fetch origin pull/2/head git checkout -b FETCH_HEAD 

7.7 Инструменты Git — Раскрытие тайн reset

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

Три дерева

Разобраться с командами reset и checkout будет проще, если считать, что Git управляет содержимым трёх различных деревьев. Здесь под «деревом» мы понимаем «набор файлов», а не специальную структуру данных. (В некоторых случаях индекс ведет себя не совсем так, как дерево, но для наших текущих целей его проще представлять именно таким.)

В своих обычных операциях Git управляет тремя деревьями:

Снимок последнего коммита, родитель следующего

Снимок следующего намеченного коммита

Указатель HEAD

HEAD — это указатель на текущую ветку, которая, в свою очередь, является указателем на последний коммит, сделанный в этой ветке. Это значит, что HEAD будет родителем следующего созданного коммита. Как правило, самое простое считать HEAD снимком вашего последнего коммита.

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

$ git cat-file -p HEAD tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf author Scott Chacon 1301511835 -0700 committer Scott Chacon 1301511835 -0700 initial commit $ git ls-tree -r HEAD 100644 blob a906cb2a4a904a152. README 100644 blob 8f94139338f9404f2. Rakefile 040000 tree 99f1a6d12cb4b6f19. lib

Команды cat-file и ls-tree являются «служебными» (plumbing) командами, которые используются внутри системы и не требуются при ежедневной работе, но они помогают нам разобраться, что же происходит на самом деле.

Индекс

Индекс — это ваш следующий намеченный коммит. Мы также упоминали это понятие как «область подготовленных изменений» Git — то, что Git просматривает, когда вы выполняете git commit .

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

$ git ls-files -s 100644 a906cb2a4a904a152e80877d4088654daad0c859 0 README 100644 8f94139338f9404f26296befa88755fc2598c289 0 Rakefile 100644 47c6340d6459e05787f644c2447d2595f5d3a54b 0 lib/simplegit.rb

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

Технически, индекс не является древовидной структурой, на самом деле, он реализован как сжатый список (flattened manifest) — но для наших целей такого представления будет достаточно.

Рабочий Каталог

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

$ tree . ├── README ├── Rakefile └── lib └── simplegit.rb 1 directory, 3 files

Технологический процесс

Основное предназначение Git — это сохранение снимков последовательно улучшающихся состояний вашего проекта, путём управления этими тремя деревьями.

Давайте рассмотрим этот процесс: пусть вы перешли в новый каталог, содержащий один файл. Данную версию этого файла будем называть v1 и изображать голубым цветом. Выполним команду git init , которая создаст Git-репозиторий, у которого ссылка HEAD будет указывать на ещё несуществующую ветку ( master пока не существует).

На данном этапе только дерево Рабочего Каталога содержит данные.

Теперь мы хотим закоммитить этот файл, поэтому мы используем git add для копирования содержимого Рабочего Каталога в Индекс.

Затем, мы выполняем команду git commit , которая сохраняет содержимое Индекса как неизменяемый снимок, создает объект коммита, который указывает на этот снимок, и обновляет master так, чтобы он тоже указывал на этот коммит.

Если сейчас выполнить git status , то мы не увидим никаких изменений, так как все три дерева одинаковые.

Теперь мы хотим внести изменения в файл и закоммитить его. Мы пройдём через всё ту же процедуру; сначала мы отредактируем файл в нашем рабочем каталоге. Давайте называть эту версию файла v2 и обозначать красным цветом.

Если сейчас мы выполним git status , то увидим, что файл выделен красным в разделе «Изменения, не подготовленные к коммиту», так как его представления в Индексе и Рабочем Каталоге различны. Затем мы выполним git add для этого файла, чтобы поместить его в Индекс.

Если сейчас мы выполним git status , то увидим, что этот файл выделен зелёным цветом в разделе «Изменения, которые будут закоммичены», так как Индекс и HEAD различны — то есть, наш следующий намеченный коммит сейчас отличается от нашего последнего коммита. Наконец, мы выполним git commit , чтобы окончательно совершить коммит.

Сейчас команда git status не показывает ничего, так как снова все три дерева одинаковые.

Переключение веток и клонирование проходят через похожий процесс. Когда вы переключаетесь (checkout) на ветку, HEAD начинает также указывать на новую ветку, ваш Индекс замещается снимком коммита этой ветки, и затем содержимое Индекса копируется в ваш Рабочий Каталог.

Назначение команды reset

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

В следующих примерах предположим, что мы снова изменили файл file.txt и закоммитили его в третий раз. Так что наша история теперь выглядит так:

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

Шаг 1: Перемещение указателя HEAD

Первое, что сделает reset — переместит то, на что указывает HEAD. Обратите внимание, изменяется не сам HEAD (что происходит при выполнении команды checkout ); reset перемещает ветку, на которую указывает HEAD. Таким образом, если HEAD указывает на ветку master (то есть вы сейчас работаете с веткой master ), выполнение команды git reset 9e5e6a4 сделает так, что master будет указывать на 9e5e6a4 .

Не важно с какими опциями вы вызвали команду reset с указанием коммита ( reset также можно вызывать с указанием пути), она всегда будет пытаться сперва сделать данный шаг. При вызове reset —soft на этом выполнение команды и остановится.

Теперь взгляните на диаграмму и постарайтесь разобраться, что случилось: фактически была отменена последняя команда git commit . Когда вы выполняете git commit , Git создает новый коммит и перемещает на него ветку, на которую указывает HEAD. Если вы выполняете reset на HEAD~ (родителя HEAD), то вы перемещаете ветку туда, где она была раньше, не изменяя при этом ни Индекс, ни Рабочий Каталог. Вы можете обновить Индекс и снова выполнить git commit , таким образом добиваясь того же, что делает команда git commit —amend (смотрите Изменение последнего коммита).

Шаг 2: Обновление Индекса (—mixed)

Заметьте, если сейчас вы выполните git status , то увидите отмеченные зелёным цветом изменения между Индексом и новым HEAD.

Следующим, что сделает reset , будет обновление Индекса содержимым того снимка, на который указывает HEAD.

Если вы указали опцию —mixed , выполнение reset остановится на этом шаге. Такое поведение также используется по умолчанию, поэтому если вы не указали совсем никаких опций (в нашем случае git reset HEAD~ ), выполнение команды также остановится на этом шаге.

Снова взгляните на диаграмму и постарайтесь разобраться, что произошло: отменен не только ваш последний commit , но также и добавление в индекс всех файлов. Вы откатились назад до момента выполнения команд git add и git commit .

Шаг 3: Обновление Рабочего Каталога (—hard)

Третье, что сделает reset — это приведение вашего Рабочего Каталога к тому же виду, что и Индекс. Если вы используете опцию —hard , то выполнение команды будет продолжено до этого шага.

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

Важно отметить, что только указание этого флага ( —hard ) делает команду reset опасной, это один из немногих случаев, когда Git действительно удаляет данные. Все остальные вызовы reset легко отменить, но при указании опции —hard команда принудительно перезаписывает файлы в Рабочем Каталоге. В данном конкретном случае, версия v3 нашего файла всё ещё остаётся в коммите внутри базы данных Git и мы можем вернуть её, просматривая наш reflog , но если вы не коммитили эту версию, Git перезапишет файл и её уже нельзя будет восстановить.

Резюме

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

1. Перемещает ветку, на которую указывает HEAD (останавливается на этом, если указана опция —soft )
2. Делает Индекс таким же как и HEAD (останавливается на этом, если не указана опция —hard )
3. Делает Рабочий Каталог таким же как и Индекс.

Reset с указанием пути

Основной форме команды reset (без опций —soft и —hard ) вы также можете передавать путь, с которым она будет оперировать. В этом случае, reset пропустит первый шаг, а на остальных будет работать только с указанным файлом или набором файлов. Первый шаг пропускается, так как HEAD является указателем и не может ссылаться частично на один коммит, а частично на другой. Но Индекс и Рабочий Каталог могут быть изменены частично, поэтому reset выполняет шаги 2 и 3.

Итак, предположим вы выполнили команду git reset file.txt . Эта форма записи (так как вы не указали ни SHA-1 коммита, ни ветку, ни опций —soft или —hard ) является сокращением для git reset —mixed HEAD file.txt , которая:

1. Перемещает ветку, на которую указывает HEAD (будет пропущено)
2. Делает Индекс таким же как и HEAD (остановится здесь)

То есть, фактически, она копирует файл file.txt из HEAD в Индекс.

Это создает эффект отмены индексации файла. Если вы посмотрите на диаграммы этой команды и команды git add , то увидите, что их действия прямо противоположные.

Именно поэтому в выводе git status предлагается использовать такую команду для отмены индексации файла. (Смотрите подробности в Отмена индексации файла.)

Мы легко можем заставить Git «брать данные не из HEAD», указав коммит, из которого нужно взять версию этого файла. Для этого мы должны выполнить следующее git reset eb43bf file.txt .

Можно считать, что, фактически, мы в Рабочем Каталоге вернули содержимое файла к версии v1, выполнили для него git add , а затем вернули содержимое обратно к версии v3 (в действительности все эти шаги не выполняются). Если сейчас мы выполним git commit , то будут сохранены изменения, которые возвращают файл к версии v1, но при этом файл в Рабочем Каталоге никогда не возвращался к такой версии.

Заметим, что как и команде git add , reset можно указывать опцию —patch для отмены индексации части содержимого. Таким способом вы можете избирательно отменять индексацию или откатывать изменения.

Слияние коммитов

Давайте посмотрим, как, используя вышеизложенное, сделать кое-что интересное — слияние коммитов.

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

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

Вы можете выполнить git reset —soft HEAD~2 , чтобы вернуть ветку HEAD на какой-то из предыдущих коммитов (на первый коммит, который вы хотите оставить):

Затем просто снова выполните git commit :

Теперь вы можете видеть, что ваша «достижимая» история (история, которую вы впоследствии отправите на сервер), сейчас выглядит так — у вас есть первый коммит с файлом file-a.txt версии v1, и второй, который изменяет файл file-a.txt до версии v3 и добавляет file-b.txt . Коммита, который содержал файл версии v2 не осталось в истории.

Сравнение с checkout

Наконец, вы можете задаться вопросом, в чем же состоит отличие между checkout и reset . Как и reset , команда checkout управляет тремя деревьями Git, и также её поведение зависит от того указали ли вы путь до файла или нет.

Без указания пути

Команда git checkout [branch] очень похожа на git reset —hard [branch] , в процессе их выполнения все три дерева изменяются так, чтобы выглядеть как [branch] . Но между этими командами есть два важных отличия.

Во-первых, в отличие от reset —hard , команда checkout бережно относится к рабочему каталогу, и проверяет, что она не трогает файлы, в которых есть изменения. В действительности, эта команда поступает немного умнее — она пытается выполнить в Рабочем Каталоге простые слияния так, чтобы все файлы, которые вы не изменяли, были обновлены. С другой стороны, команда reset —hard просто заменяет всё целиком, не выполняя проверок.

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

Например, пусть у нас есть ветки master и develop , которые указывают на разные коммиты и мы сейчас находимся на ветке develop (то есть HEAD указывает на неё). Если мы выполним git reset master , сама ветка develop станет ссылаться на тот же коммит, что и master . Если мы выполним git checkout master , то develop не изменится, но изменится HEAD. Он станет указывать на master .

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

С указанием пути

Другой способ выполнить checkout состоит в том, чтобы указать путь до файла. В этом случае, как и для команды reset , HEAD не перемещается. Эта команда как и git reset [branch] file обновляет файл в индексе версией из коммита, но дополнительно она обновляет и файл в рабочем каталоге. То же самое сделала бы команда git reset —hard [branch] file (если бы reset можно было бы так запускать) — это небезопасно для рабочего каталога и не перемещает HEAD.

Также как git reset и git add , команда checkout принимает опцию —patch для того, чтобы позволить вам избирательно откатить изменения содержимого файла по частям.

Заключение

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

Ниже приведена памятка того, как эти команды воздействуют на каждое из деревьев. В столбце «HEAD» указывается «REF» если эта команда перемещает ссылку (ветку), на которую HEAD указывает, и «HEAD» если перемещается только сам HEAD. Обратите особое внимание на столбец «Сохранность рабочего каталога?» — если в нём указано НЕТ, то хорошенько подумайте прежде чем выполнить эту команду.

На уровне коммитов