Когда ElpieKay ответил в комментарии , используйте git fetch <em>remote</em> HEAD, который сохраняет идентификатор хэша выбранной фиксации в специальном файле FETCH_HEAD.Затем вы можете использовать FETCH_HEAD в качестве ссылки, пока следующая git fetch не перезапишет его.
Обсуждение
Операции извлечения и выталкивания работают с именами, но они не симметричны.
Они симметричны , когда речь идет о передаче коммитов .То есть, независимо от того, запускаете ли вы git fetch <em>remote</em> [<em>refspec...</em>] или git push <em>remote</em> [<em>refspec...</em>], отправляющая и получающая системы Git ведут диалог с использованием хеш-идентификаторов объектов, в котором отправитель объявляет, какие хеш-идентификаторы отправитель хотел бы передать получателю: для вас , и получатель отправляет обратно ответы, в которых говорится, что отправитель должен отправить это, или - если получатель уже имеет этот объект - не отправлять его.(Это немного сложнее, чем это, поскольку приемник-получатель запускает процесс с первыми «желаниями», но достаточно близко.)
Когда это будет сделано, операция push имеетотправитель отправить через серию рекомендуемыхпары: Пожалуйста, установите refs/heads/master на a123456..., например.Это означает, что если вы делаете git push пока вы находитесь в отдельном HEAD в вашем хранилище, вам все равно придется дать other Git имя для этого коммита: *Например, 1035 *
git push origin HEAD:refs/heads/somebranch
достаточно, чтобы ваш Git отправил хэш-идентификатор для вашего HEAD коммита, но рекомендую, чтобы его Git установил их refs/heads/somebranch на , чтобыID хеша, когда закончите.Вы не можете попросить их установить HEAD: если вы попытаетесь, они просто создадут ветку с именем HEAD, то есть refs/head/HEAD, если вы сейчас находитесь на ветке или отклонитеваш push-запрос, если нет:
error: unable to push to unqualified destination: HEAD
С другой стороны, когда вы запускаете git fetch, , вы контролируете, какие ссылки, если они есть, обновляются с вашей стороны.Их Git просто отправляет список всех их ссылок (во всяком случае, в протоколе v0; v2 более привлекательный).Ваш Git выбирает список, и, если они отправили вам новые хэш-идентификаторы для своих refs/heads/master и refs/heads/branch, ваш Git, как правило, обновит ваши собственные refs/remotes/origin/master и refs/remotes/origin/branch.Ваш Git берет список их ссылок, генерирует список желаемых хеш-идентификаторов вашей стороны и передает его отправителю, чтобы начать разговор по хеш-идентификатору has / want.
То есть, это то, что ваш Gitделает, если вы запускаете git fetch origin, с без добавленных refspec аргументов и предполагая, что ваша конфигурация нормальная (не особая конфигурация, оставленная, например, для клона --single-branch),Но если вы do добавляете аргументы refspec, например:
git fetch origin refs/heads/master:refs/weird/name
, тогда ваш Git просит свой Git отправлять только те коммиты, которые вам нужны для работы с их master.То есть разговор «иметь / хочу» начинается с только хеш-идентификатора в их refs/heads/master (и даже тогда, только если у вас его еще нет).Когда все имеют / хотят, и объекты поступили в ваш репозиторий, ваш Git затем создает или обновляет вашу ссылку refs/weird/name.
Помните, что эти ссылки имеют общую форму <em>src</em>:*dst.Часть src - это ссылка на источник - имя или хэш-идентификатор, который отправитель использует для поиска фиксации, а часть dst - это адрес назначения , который получатель должен использовать для запоминания хеш-идентификатора в конце.Вы можете опустить одно из двух значений, написав src или :<em>dst</em>, что имеет различные значения в особых случаях в зависимости от push vs fetch.Работает ли необработанный хэш-идентификатор в части src этого выражения, зависит от двух вещей:
- , если вы делаете
push, оно всегда работает (до тех пор, покапоскольку объект существует); - , если вы делаете
fetch, он работает тогда и только тогда, когда они позволяют это.
(Итак, здесь мы уже видим эту выборку итолчок асимметричен.)
Фоr git fetch, если вы пропустите часть :<em>dst</em> в refspec - например, git fetch origin refs/heads/master или git fetch origin master - ваш Git пропускает часть создания или обновления, за исключением так называемых условных обновлений (создание или обновление refs/remotes/origin/master, в данном случае).Однако для каждого имени, которое вы получили git fetch, ваш Git всегда пишет, чтосвязать с вашим FETCH_HEAD файлом:
$ git fetch origin HEAD master
From ...
* branch HEAD -> FETCH_HEAD
* branch master -> FETCH_HEAD
$ cat .git/FETCH_HEAD
f84b9b09d40408cf91bbc500d9f190a7866c3e0f <url>
f84b9b09d40408cf91bbc500d9f190a7866c3e0f branch 'master' of <url>
(Обратите внимание, что хотя git fetch получил много ветвей и тегов в списке пар имя / идентификатор из origin, мы только спросили для HEAD и master, так вот что git fetch записало в .git/FETCH_HEAD.)
Заключение
Если вы отправляете коммиты, вы должен предоставить имя для другого Git.Обычно подразумевается имя: вы нажимаете свою ветку bran, поэтому имя, которое вы хотите их установить, равно их ветка bran.Вы можете толкнуть любой объект: после получения объекта его Git решает, принимать лиспаривание.Обычно вы будете выдвигать объект коммита, который будет перетаскивать вместе с ним все остальные необходимые объекты, и вам будет предложено установить имя ветви.
Если вы получаете коммитытем не менее, вам не нужно указывать имя на вашей стороне .Их Git отправит их имена и объекты, а ваш Git будет использовать ваш файл .git/FETCH_HEAD для запоминания хеш-идентификаторов, которые вы получили от них.Если вы предоставляете имена на своей стороне, ваш Git обновит эти имена, а если вы этого не сделаете, у Git есть несколько сложных правил выборки по умолчанию, чтобы запомнить их имена ветвей через refs/remotes/<em>remote</em>/ names.
ХотяHEAD само по себе не является ответвлением name, оно является действительным name .Возможно, вы не сможете заставить их обновить свои отключенные HEAD (через push), но вы обычно можете попросить их отправить вам хеш коммита, сохраненный в их отключенных HEAD, что ваш Git будетпомните как "неназванный" в вашем .git/FETCH_HEAD.