Что означает 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/<branch>, но с внутренним использованием FETCH_HEAD вместо того, чтобы ссылаться на любую полученную единственную ссылку, вместо того, чтобы указывать вещи.

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

Итак, если я выдам:

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

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

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

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

git merge FETCH_HEAD

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

71f026561ddb57063681109aadd0de5bac26ada9                        branch 'some-branch' of <remote URL>
669980e32769626587c5f3c45334fb81e5f44c34        not-for-merge   branch 'some-other-branch' of <remote URL>
b858c89278ab1469c71340eef8cf38cc4ef03fed        not-for-merge   branch 'yet-some-other-branch' of <remote URL>

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

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

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

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

На самом деле ... не всегда, учитывая, что в Git 2.29 (4 квартал 2020 г.) _ 2_ ^{(человек)} изучил параметр --no-write-fetch-head, чтобы избежать записи FETCH_HEAD файла.

См. commit 887952b (18 августа 2020 г.) по Junio ​​C Hamano (gitster).
^{(Объединено Junio ​​C Hamano - gitster - в фиксации b556050, 24 августа 2020 г.)}

fetch: при необходимости разрешить отключение FETCH_HEAD update

^{Подписано: Деррик Столи}

Если вы запускаете выборку, но записываете результат в ветки удаленного отслеживания, и либо если вы ничего не делаете с полученными ссылками (например, вы просто зеркалируете), либо если вы всегда работаете из ссылок удаленного отслеживания (например, вы извлекаете и затем объединяете origin/branchname отдельно), вы можете обойтись без FETCH_HEAD вообще.

Научите git fetch ^(man) параметр командной строки --[no-]write-fetch-head.

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

Обратите внимание, что в режиме --dry-run FETCH_HEAD никогда не записывается; в противном случае вы увидите в файле список объектов, которых у вас на самом деле нет.

Передача --write-fetch-head не заставляет [git fetch](https://github.com/git/git/blob/887952b8c680626f4721cb5fa57704478801aca4/Documentation/git-fetch.txt)<sup>([man](https://git-scm.com/docs/git-fetch))</sup> записывать файл.

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

--[no-]write-fetch-head

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

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

Также обратите внимание: по-прежнему с Git 2.29 (4 квартал 2020 г.) FETCH_HEAD теперь всегда читается из файловой системы независимо от используемого бэкэнда ref, поскольку его формат намного богаче, чем у обычных ссылок, и записывается непосредственно с помощью _ 28_ ^(man) в виде простого файла ..

См. фиксацию e811530, совершить 5085aef, > 4877c6c, совершить e39620f (19 августа 2020 г.) от Han-Wen Nienhuys (hanwen).
^{(объединено Junio ​​C Hamano - gitster - в commit 98df75b, 27 августа 2020 г.)}

refs: читать FETCH_HEAD и MERGE_HEAD в целом

^{Подписано: Хан-Вен Ниенхуйс}

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

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

В Git 2.29 (4 квартал 2020 г.) обновления для получения кода по требованию в лениво клонированных репозиториях.

См. фиксацию db3c293 (2 сентября 2020 г.) и зафиксировать 9dfa8db, совершить 7ca3c0a, зафиксировать 5c3b801, = "https://github.com/git/git/commit/abcb7eeb31d0267ada469646be993ad25e127d0d" rel = "nofollow noreferrer"> совершить abcb7ee, совершить e5b9421, Junio ​​C Hamano - gitster - в commit b4100f3, 3 сен 2020 г.)

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

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

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

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

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

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