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?


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.


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.


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. :)


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 ...”


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 "you@example.com"; 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 "you@example.com"; 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: 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)

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.


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ć.


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

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,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.