Почему «origin / HEAD» отображается при запуске «git branch -r»?


160

Когда вы бежите, git branch -rпочему это список origin/HEAD? Например, на GitHub есть удаленное репо, скажем, с двумя ветками: master и awesome-feature. Если я git cloneзахвачу его, а затем зайду в свой новый каталог и выведу список ветвей, я увижу это:

$ git branch -r
origin/HEAD
origin/master
origin/awesome-feature

Или в любом другом порядке (альфа? Я подделываю этот пример, чтобы сохранить личность невинного репо в тайне). Так в чем же HEADдело? Является ли это то , что последний человек , pushимел их HEADзаостренные в том, когда они вытолкнули? Разве это не всегда будет тем, чем они были push? HEADs двигаться вокруг ... почему меня волнует, на что кто-то HEADуказывает на другую машину?

Я просто разбираюсь с удаленным отслеживанием и тому подобным, так что это одна давняя путаница. Спасибо!

РЕДАКТИРОВАТЬ: у меня сложилось впечатление, что выделенные удаленные репозитории (например, GitHub, где никто не будет ssh и работать над этим кодом, но только тянуть или толкать и т. Д.) Не имели и не должны иметь HEAD, потому что, в основном, было нет рабочей копии. Не так?


Ответы:


140

@robinst правильно.

В git вы можете выбрать, какая ветвь извлекается по умолчанию (например, когда вы клонируете). По умолчанию origin/HEADбудет указывать на это.

На GitHub Вы можете изменить это в настройках администратора для своего репозитория GitHub. Вы также можете сделать это из командной строки через

git remote set-head origin trunk

или удалить его полностью через

git remote set-head origin -d

Пример . Посмотрите на выпадающий список «Switch Branches». trunkпроверяется, поэтому origin/HEADследует trunk.


Я переименовал другой пульт, чтобы быть, originи мой otherremote/HEAD -> masterбеспокоил меня. Запуск вашей команды исправил это для меня.
Фелипе Альварес

59

Причина, по которой пустой репозиторий может иметь HEAD, заключается в том, что он определяет, какая ветвь первоначально извлекается после клона репозитория.

Обычно HEAD указывает на master, и это ветвь, которая проверяется, когда люди клонируют репозиторий. Установка его в другую ветку (путем редактирования HEAD в пустом хранилище) приводит к тому, что эта ветвь извлекается на клоне.


2
Поскольку эту ссылку можно удалить, не нажимая кнопку, origin/HEADправильная ли локальная ссылка? Удаляет ли это удаление origin?
Зак Постен

@zposten: Нет, так же, как удаление origin/masterне влияет на пульт.
Робинст

Это означало бы, что после клонирования ссылка - просто бесполезная часть информации.
Бахсау

@ Бахсау ссылка не клонируется.
Робинст

27

У меня сложилось впечатление, что у выделенных удаленных репозиториев (таких как GitHub, где никто не будет работать с ssh и работать с этим кодом, а только вытащить или нажать и т. Д.) Не было и не должно быть HEAD, потому что, по сути, не было работы копировать. Не так?

У меня было точно такое же впечатление, как ты сказал.

И я даже не могу удалить эту ветку удаленного слежения origin / HEAD, клонированную из github, выполнив

git branch -d -r origin/HEAD

Это не имело никакого эффекта.

Может кто-нибудь сказать мне, как я могу удалить эту ветку удаленного отслеживания origin / HEAD?

Обновить

Хотя я не нашел, почему при клонировании из github создается origin / HEAD, я нашел способ удалить его.

Новая версия Git обеспечить

git remote set-head <name> -d

удалить бесполезный указатель HEAD ветки удаленного слежения.

И мы также можем изменить тупое имя по умолчанию «origin» на любое, используя

git remote rename origin <new_name>

Надеюсь, это поможет. :)


У меня такая же проблема (даже на GitHub), и set-head не работает. Должен ли я запускать 'git remote set-head HEAD -d'?
Joost Schuur

5
@Joost: этоgit remote set-head origin -d
znq

13

Вы правы, что переход к выделенным удаленным репозиториям работает намного лучше, когда они «голые», то есть когда у них нет рабочих каталогов. Архитектура Git предназначена для обновления с помощью патчей или pull( fetch), что имеет смысл в распределенной VCS. Как говорят где-то в документах, нажатие на ветку, которая в настоящий момент извлечена, может привести к «неожиданным результатам» .

HEAD является частью требований к действительному хранилищу. Git Repository Layout говорит, частично:

HEAD

A symref (see glossary) to the refs/heads/ namespace describing the currently active  
branch. It does not mean much if the repository is not associated with any working tree  
(i.e. a bare repository), but a valid git repository must have the HEAD file; some  
porcelains may use it to guess the designated "default" branch of the repository  
(usually master). It is legal if the named branch name does not (yet) exist.

Таким образом, вы увидите HEAD как часть списка веток, даже если «это не много значит ...»


Это не имеет смысла. Репозитории начинаются с нуля, но в ту минуту, когда вы что-то добавляете к ним, они перестают быть пустыми, и если вы запустите на них «git branch», они покажут текущую извлеченную ветку.
геоидезическая

@geoidesic Репозиторий может быть пустым, даже если вы нажали на него. Следующее: mkdir foobar; cd foobar; git init --bare; cd ..; git clone foobar foobar_clone; cd foobar_clone; touch file; git add file; git config --global user.email "you@example.com"; git config --global user.name "Your Name"; git commit -m "test"; git push origin master; cd ..; cd foobar; git config core.bareвыводит true. Также на этих командах нет рабочей копии помещенного файла в репозитории foobar.
Андерс Линден

@geoidesic Репозиторий может быть пустым, даже если вы нажали на него. Следующее: mkdir foobar; cd foobar; git init --bare; cd ..; git clone foobar foobar_clone; cd foobar_clone; touch file; git add file; git config user.email "you@example.com"; git config user.name "Your Name"; git commit -m "test"; git push origin master; cd ..; cd foobar; git config core.bareвыводит true. Также на этих командах нет рабочей копии помещенного файла в репозитории foobar.
Андерс Линден

@geoidesic A --bare git repo просто означает репо без рабочего дерева, то есть репо, которое содержит только каталог .git, но не может иметь никаких извлеченных файлов. Поскольку он не может иметь никаких извлеченных файлов, на самом деле у него даже нет каталога .git, он просто помещает все файлы .git непосредственно в главный каталог. Создайте и вы увидите!
00prometheus

5

Если «origin» - это удаленный репозиторий, origin / HEAD определяет ветвь по умолчанию в этом удаленном репозитории.

Пример:

$ git remote show
origin
$ git remote show origin
* remote origin
  Fetch URL: git@github.com:walkerh/pipe-o-matic.git
  Push  URL: git@github.com:walkerh/pipe-o-matic.git
  HEAD branch: master
  Remote branch:
    master tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local ref configured for 'git push':
    master pushes to master (fast-forwardable)

Обратите внимание на строку с надписью «HEAD branch: master». Именно здесь удаленный репозиторий позволяет клиентам узнать, какую ветку оформить по умолчанию.


1

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


2
В репозиториях github нет проверенных веток. Я не понимаю, почему это применимо.
Дастин

Удаленные репозитории НЕ должны иметь рабочий каталог. Удаленные репозитории должны быть --bare и, следовательно, не могут иметь ветки, которые были извлечены в данный момент.
n4rzul

-14

Я предполагаю, что кто-то толкнул ветку и назвал ее ГОЛОВОЙ:

git push origin HEAD

Могу ли я получить некоторые комментарии относительно того, что не так с этим? Если вы хотите использовать origin / HEAD на github, я знаю, что это единственный способ получить его там.
Дастин

Удаленная ГОЛОВА - это символическая ссылка (обычно это ссылки / главы / мастера). Вы замените символьный ref хеш-идентификатором коммита вашей текущей ветки.
Даниэль Фанжул

2
Разве догадки не должны обсуждаться в комментариях, а не быть неточным ответом?
Лучано
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.