git FETCH_HEAD недолгая ссылка

Question

1. Я прочитал здесь , что git FETCH_HEAD - недолгая ссылка.Каков срок службы ссылки git FETCH_HEAD?

2. Когда я делаю git fetch origin, в таких случаях обновляется много веток удаленного отслеживания.Куда будет указывать FETCH_HEAD?

Answer 1

Как сказано в gitrevisions ,

FETCH_HEAD записывает ветку, которую вы выбрали из удаленного репозитория с вашим последним вызовом git fetch.

FETCH_HEAD создается первым git fetch и будет обновляться git fetch.Под git fetch это также означает git pull, поскольку git pull может быть git fetch + git merge или git fetch + git rebase.

Для git fetch origin foo, несомненно, FETCH_HEAD указывает на верхушку foo.foo является действительным ссылочным номером, который можно получить из удаленного хранилища.В некоторых редких случаях foo может быть хешем определенного объекта (фиксация, дерево, блоб или тег), если uploadpack.allowTipSHA1InWant установлено в true в удаленном хранилище, а затем FETCH_HEAD будет указывать на объект.

Это становится сложным, когда дело доходит до git fetch или git fetch origin.Что будет обновляться до * 1031?Есть много случаев.Например, локальный репозиторий находится в отдельном HEAD, в конкретной ветви с восходящим потоком, в ветви без восходящего потока или в некоторых других случаях.Если не копать так глубоко, мы можем узнать результат из git fetch.Вот пример,

remote: Counting objects: 11, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 11 (delta 7), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
From D:/hello
   ca2d63e..38d365c  ost        -> origin/ost
 * [new branch]      a          -> origin/a
   8fe4b12..db5a0d9  aaa        -> origin/aaa
   36ca690..e00229b  haha       -> origin/haha
   c96b459..5ab6097  master     -> origin/master
   283a081..004375e  mist       -> origin/mist

Мы можем видеть, что вывод говорит, что ссылки обновляются на git fetch.FETCH_HEAD всегда указывает на подсказку первого рефери.В этом примере FETCH_HEAD - это совет origin/ost, 38d365c.Это также верно при извлечении только одного ссылки или одного объекта.

Если процесс git fetch завершится неудачно, FETCH_HEAD станет неизвестной ревизией.Файл .git/FETCH_HEAD все еще существует, и он просто пуст.

Answer 2

1. Это не совсем реальная ссылка вообще;ссылка - это указатель на один коммит (или, в случае HEAD, имя ветки).FETCH_HEAD вместо этого - метаданные git о ветвях, которые были выбраны последними.Он живет до тех пор, пока не будет перезаписан другим извлечением

2. Это неверная ссылка и содержит все информацию об удаленной информации отслеживания, которая былаfetched.

Когда вы запускаете git merge FETCH_HEAD (или делаете это неявно, запуская git pull), git обрабатывает это специально, а не как обычную ссылку.Вместо этого будет использован файл FETCH_HEAD, и git будет искать ветку, для которой не указан специальный токен not-for-merge.Эта ветвь будет той, которая используется для слияния.(Git определил эту ветку на основе ветви удаленного отслеживания, соответствующей вашему вызову git fetch или ветви, в которой вы работали при запуске.)

Обратите внимание, что в FETCH_HEAD - подробности об удаленной ветвитакже включены, что позволяет git создать сообщение для коммита слияния, в котором указаны , откуда эта ветвь(например, «Merge of branch 'master' of https://my.visualstudio.com/my/repository»).

FETCH_HEAD, как и большая часть метаданных git-репозитория, представляет собой просто текстовый файл;Прочитав его, вы увидите, как он меняется после каждой выборки.(Например, вы можете видеть, что ответ, на который вы ссылаетесь, ужасно неправильный и что FETCH_HEAD содержит , а не содержит информацию об одной ветви, она содержит все ветви напульт.) ?