Dlaczego „origin / HEAD” jest pokazywany podczas uruchamiania „git branch -r”?

160

Kiedy git branch -rbiegasz, dlaczego do licha ma listę origin/HEAD? Na przykład istnieje zdalne repozytorium na GitHub, powiedzmy, z dwiema gałęziami: master i awesome-feature. Jeśli zrobię, git cloneaby go pobrać, a następnie przejść do mojego nowego katalogu i wyświetlić listę gałęzi, widzę to:

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

Albo w jakimkolwiek porządku (alfa? Udaję ten przykład, aby zachować w tajemnicy tożsamość niewinnego repozytorium). Więc o co chodzi HEAD? Czy to co ostatnią osobą, która pushmiała ich HEADwskazał kiedy pchali? Czy to nie zawsze będzie tym, czym oni byli push? HEADs poruszać się ... dlaczego mnie obchodzi, na co ktoś HEADwskazuje na innym komputerze?

Po prostu rozumiem zdalne śledzenie i takie tam, więc jest to jedno trwałe zamieszanie. Dzięki!

EDYCJA: Miałem wrażenie, że dedykowane zdalne repozytoria (takie jak GitHub, gdzie nikt nie będzie ssh wchodził i nie pracował nad tym kodem, ale tylko ciągnie lub pchają itp.) Nie i nie powinien mieć HEAD, ponieważ w zasadzie istniał brak kopii roboczej. Skąd?

Ben Hamill
źródło

Odpowiedzi:

140

@robinst jest poprawne.

W git możesz wybrać, która gałąź jest domyślnie pobierana (np. Kiedy klonujesz). Domyślnie origin/HEADbędzie na to wskazywać.

W serwisie GitHub możesz to zmienić w ustawieniach administratora repozytorium GitHub. Możesz to również zrobić z wiersza poleceń za pomocą

git remote set-head origin trunk

lub usuń go całkowicie za pośrednictwem

git remote set-head origin -d

Przykład . Spójrz na menu rozwijane „Przełącz gałęzie”. trunkjest zaznaczone, więc origin/HEADnastępuje trunk.

cdunn2001
źródło
Zmieniłem nazwę na innego pilota origini otherremote/HEAD -> masterprzeszkadzał mi. Wykonanie twojego polecenia naprawiło to dla mnie.
Felipe Alvarez
59

Powodem, dla którego nagie repozytorium może mieć HEAD, jest to, że określa, która gałąź jest początkowo wypisywana po sklonowaniu repozytorium.

Zwykle HEAD wskazuje na master, a to jest gałąź, która jest sprawdzana, kiedy ludzie klonują repozytorium. Ustawienie go na inną gałąź (poprzez edycję HEAD w czystym repozytorium) powoduje, że ta gałąź jest wyewidencjonowana na klon.

robinst
źródło
2
Ponieważ można usunąć to odniesienie bez wciskania, origin/HEADczy lokalne odniesienie jest poprawne? Czy jej usunięcie ma wpływ na origin?
Zach Posten,
@zposten: Nie, w ten sam sposób, w jaki usuwanie origin/masternie wpływa na pilota.
robinst
Oznaczałoby to, że po sklonowaniu odniesienie jest tylko bezużyteczną informacją.
Bachsau
@Bachsau odniesienie nie jest klonowane.
robinst
27

Miałem wrażenie, że dedykowane zdalne repozytoria (takie jak GitHub, gdzie nikt nie będzie ssh wchodził i nie pracował nad tym kodem, ale tylko ciągnie lub pcha itp.) Nie ma i nie powinien mieć HEAD, ponieważ w zasadzie nie było działania Kopiuj. Skąd?

Miałem dokładnie takie samo wrażenie, jak powiedziałeś.

I nawet nie mogę usunąć tej gałęzi zdalnego śledzenia pochodzenia / HEAD sklonowanej z github przez wykonanie

git branch -d -r origin/HEAD

Nie przyniosło to żadnego skutku.

Czy ktoś może mi powiedzieć, jak mogę usunąć tę gałąź zdalnego śledzenia pochodzenia / HEAD?

aktualizacja

Chociaż nie znalazłem, dlaczego istnieje źródło / HEAD utworzone podczas klonowania z github, znajduję sposób, aby go usunąć.

Nowa wersja git zapewnia

git remote set-head <name> -d

aby usunąć bezużyteczny wskaźnik HEAD gałęzi zdalnego śledzenia.

Możemy również zmienić głupią domyślną nazwę „pochodzenie” na cokolwiek chcemy, używając

git remote rename origin <new_name>

Mam nadzieję, że to pomoże. :)

boblu
źródło
Mam ten sam problem (nawet na GitHubie), a funkcja set-head nie działa. Czy powinienem uruchomić 'git remote set-head HEAD -d'?
Joost Schuur
5
@Joost: togit remote set-head origin -d
znq
13

Masz rację, że wypychanie do dedykowanych repozytoriów zdalnych działa znacznie lepiej, gdy są „puste”, to znaczy, gdy nie mają działających katalogów. Architektura Gita jest zaprojektowana do aktualizowania przez poprawki lub pull( fetch), co ma sens w rozproszonym VCS. Jak gdzieś mówią dokumenty, wypchnięcie do gałęzi, która jest aktualnie wyewidencjonowana, może spowodować „nieoczekiwane wyniki” .

HEAD jest częścią wymagań dotyczących prawidłowego repozytorium. Układ repozytorium Git mówi po części:

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.

Więc zobaczysz HEAD jako część listy gałęzi, nawet jeśli „to niewiele znaczy ...”

Paweł
źródło
To nie ma sensu. Repozytoria na początku są puste, ale w chwili, gdy coś do nich wrzucisz, nie są już puste i jeśli uruchomisz na nich "git branch", pokażą aktualnie wyewidencjonowaną gałąź.
geoidesic
@geoidesic Repozytorium może być puste, nawet jeśli do niego przeszedłeś. Następujące: 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 "[email protected]"; git config --global user.name "Your Name"; git commit -m "test"; git push origin master; cd ..; cd foobar; git config core.barezwraca wartość true. Nie ma również kopii roboczej przesłanego pliku w repozytorium foobar po tych poleceniach.
Anders Lindén
@geoidesic Repozytorium może być puste, nawet jeśli do niego przeszedłeś. Następujące: 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 "[email protected]"; git config user.name "Your Name"; git commit -m "test"; git push origin master; cd ..; cd foobar; git config core.barezwraca wartość true. Nie ma również kopii roboczej wypchniętego pliku w repozytorium foobar po tych poleceniach.
Anders Lindén
@geoidesic A --bare git repo oznacza po prostu repozytorium bez drzewa roboczego, tj. repozytorium, które zawiera tylko katalog .git, ale nie może w ogóle mieć wypisanych plików. Ponieważ nie może mieć żadnych pobranych plików, w rzeczywistości nie ma nawet katalogu .git, po prostu umieszcza wszystkie pliki .git bezpośrednio w katalogu głównym. Utwórz jeden, a zobaczysz!
00prometeusz
5

Jeśli „źródło” jest zdalnym repozytorium, to źródło / HEAD identyfikuje domyślną gałąź w tym zdalnym repozytorium.

Przykład:

$ git remote show
origin
$ git remote show origin
* remote origin
  Fetch URL: [email protected]:walkerh/pipe-o-matic.git
  Push  URL: [email protected]: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)

Zwróć uwagę na linię z napisem „HEAD branch: master”. W tym miejscu repozytorium zdalne informuje klientów, z której gałęzi mają domyślnie pobierać płatności.

Walker Hale IV
źródło
1

Zawsze jest nagłówek HEAD wskazujący na aktualnie wyewidencjonowaną gałąź w zdalnym repozytorium (która może być główną lub nie). Nawet zdalne repozytoria mają aktualne gałęzie. Zwykle jest to mistrz i nie przychodzi mi do głowy żaden powód, dla którego ktoś chciałby to zmienić, ale można to zmienić.

codelogic
źródło
2
repozytoria github nie mają sprawdzonych gałęzi. Nie rozumiem, dlaczego miałoby to mieć zastosowanie.
Dustin,
Zdalne repozytoria NIE powinny mieć katalogu roboczego. Zdalne repozytoria powinny być --bare i dlatego nie mogą mieć aktualnie pobranej gałęzi.
n4rzul
-14

Domyślam się, że ktoś pchnął gałąź i nazwał ją HEAD:

git push origin HEAD
Dustin
źródło
Czy mogę uzyskać komentarze, co jest w tym złego? Jeśli chcesz mieć źródło / HEAD na githubie, to jedyny sposób, w jaki go tam znam.
Dustin,
Zdalna HEAD jest symbolicznym odniesieniem (zwykle do refs / heads / master). Zastąpisz symboliczny odnośnik hash id zatwierdzenia aktualnej gałęzi.
Daniel Fanjul
2
Czy nie powinno się omawiać domysłów w komentarzach, zamiast być nieprecyzyjną odpowiedzią?
Luciano,