Wie bekomme ich den Standard-Git-Branch?

Lesezeit: 8 Minuten

Benutzeravatar von lfender6445
lfender6445

Mein Team wechselt zwischen der Verwendung von dev und master als Standard-Zweig für mehrere Repos und ich möchte ein Skript schreiben, das beim Betreten eines Verzeichnisses nach dem Standard-Zweig sucht.

Wenn Pull-Requests in einigen dieser Repos geöffnet werden, sind sie standardmäßig entweder „dev“ oder „master“ als Zusammenführungsziel.

Ich verstehe, wie diese Informationen eingestellt, aber nicht abgerufen werden:
https://help.github.com/articles/setting-the-default-branch/

Ist ein Git-Befehl verfügbar, um den Standardzweig für das Remote-Repository zu bestimmen?

  • Der Standard-Zweig ist ein Github-Ding, kein Git-Ding.

    – Ismail Badawi

    23. Februar 2015 um 3:10 Uhr

  • Sie können die GitHub-API wie in dieser Frage verwenden: stackoverflow.com/questions/16500461/…

    – Ismail Badawi

    23. Februar 2015 um 3:15 Uhr

  • @IsmailBadawi Wirklich? Wenn Sie ein lokales Bare-Repo erstellen und darauf einen Klon ausführen, muss es immer noch eine Logik geben, die bestimmt, welcher Zweig standardmäßig ausgecheckt wird, oder?

    – bluenote10

    16. Juli 2019 um 7:33 Uhr

  • Keine der folgenden Lösungen funktioniert zuverlässig für mich: wenn ich in der Branche bin featuregegabelt von developes wird mich zurückbringen develop und nicht master (oder mainaus denen develop ist eine Gabel) … Irgendwelche Hilfe?

    – Benutzer3341592

    12. Januar 2021 um 16:02 Uhr

  • Frage gestellt in stackoverflow.com/questions/65703168/…

    – Benutzer3341592

    13. Januar 2021 um 13:42 Uhr

Benutzeravatar von Radon8472
Radon8472

Ich habe einen Weg gefunden, den Standardzweig zu erkennen, wenn er nicht Master ist.

git remote show [your_remote] | sed -n '/HEAD branch/s/.*: //p'

Ich habe es mit mehreren Repos von Gitlab getestet und es hat gut funktioniert. (für die meisten Situationen [your_remote] wird sein originLauf git remote um den Namen Ihrer Fernbedienung zu überprüfen)

  • Das hat bei mir gut funktioniert, außer dass der Cut-Befehl ein Leerzeichen vor dem eigentlichen Branch-Namen lässt, was bei der Verwendung aus Skripten zu Problemen führen kann. Am Ende habe ich verwendet git remote show upstream | grep "HEAD branch" | sed 's/.*: //'

    – JHH

    9. Oktober 2018 um 12:01 Uhr

  • Beste Methode bisher. Ich habe aus irgendwelchen Gründen nicht einmal refs/remotes/origin/HEAD.

    – Loïc Faure-Lacroix

    11. Oktober 2018 um 16:08 Uhr

  • Ich habe es so aktualisiert, um das Leerzeichen zu entfernen git remote show origin | grep 'HEAD branch' | cut -d' ' -f5

    – Andreas

    20. September 2019 um 16:56 Uhr

  • Beachten Sie, dass dies für einige (ältere) Versionen von Git möglicherweise nicht funktioniert, vorausgesetzt, Sie haben einen mehrdeutigen HEAD. Siehe zB diesen Beitrag

    – David Střelák

    27. September 2019 um 9:53 Uhr

  • Dies funktioniert nicht, wenn git unter einem nicht-englischen Gebietsschema ausgeführt wird. Zum Beispiel mit einem deutschen Gebietsschema HEAD branch buchstabiert ist Hauptbranch. Um dies zu beheben, verwenden Sie: LC_ALL=C git remote show origin | sed -n '/HEAD branch/s/.*: //p'

    – Slaven Rezic

    23. März 2022 um 16:15 Uhr

Benutzeravatar von danielkza
Danielkza

Getestet mit Git 2.9.4 (funktioniert aber möglicherweise in anderen Versionen) in einem von Github geklonten Repo:

git symbolic-ref refs/remotes/origin/HEAD | sed '[email protected]^refs/remotes/origin/@@'

Beispielausgabe:

master

  • Wenn ich den Standardzweig auf der Serverseite (Github) ändere, erhält dies immer noch den alten Standard in einem alten, aber ansonsten aktuellen Klon (aber frische Klone sind in Ordnung). Wie erzwingt man hier ein Update?

    – nö

    5. April 2018 um 15:20 Uhr

  • Vielleicht mache ich etwas falsch, aber wenn ich das ausführe, bekomme ich: fatal: ref refs/remotes/origin/HEAD is not a symbolic ref mit Git 2.19.1.

    – Christianbundy

    2. November 2018 um 17:03 Uhr

  • Diese Methode kann fehlschlagen oder falsche Ergebnisse zurückgeben. Die Referenz kann eher ein Hash sein, der nicht in eine Verzweigung aufgelöst werden kann, als eine symbolische Referenz. Dies kann auch durch Betrachten von HEAD gelöst werden. Trotzdem habe ich in 6528 Repositories die beiden überprüft git symbolic-ref Methoden liefern falsche Ergebnisse (z master eher, als develop Pro Alfresco/chef-alfresco) in 172 Fällen. Die git remote show Die von @ Radon8472 vorgeschlagene Methode ist zuverlässiger und scheint in einigen der 172 abweichenden Fälle, die ich von Hand überprüft habe, das richtige Ergebnis zurückzugeben.

    – Diomidis spinellis

    25. Januar 2019 um 15:20 Uhr

  • Sie können auch verwenden Basisname statt sed basename $(git symbolic-ref refs/remotes/origin/HEAD)

    – OzzyCzech

    26. März 2019 um 11:20 Uhr

  • Um diese symbolische Referenz vom Upstream zu synchronisieren, git remote set-head origin --auto. Dies aktualisiert sowohl das, was in gesehen wird git remote show und die symbolische Referenz, auf die hier verwiesen wird.

    – Eduard Anderson

    14. Januar 2020 um 14:46 Uhr

git rev-parse --abbrev-ref origin/HEAD wird drucken origin/<default-branch-name>. Die git symbolic-ref Antworten machen das Gleiche, brauchen aber eine längere Argumentation.

Wenn die origin Das Repository ändert dann seinen Standard-Zweignamen git remote set-head origin -a ruft den neuen Standard-Zweignamen ab.

  • Dies läuft viel schneller als git remote show, weil es lokale Informationen verwendet, ohne die Gegenstelle abzufragen. Sie können die ersten 7 Zeichen (zB “origin/”) abschneiden und erhalten nur den Zweignamen mit git rev-parse --abbrev-ref origin/HEAD | cut -c8-.

    – Scottlocke

    15. Juni 2021 um 0:20 Uhr

  • Ist dies nicht eigentlich die kanonische Antwort, da sie einen Installationsbefehl verwendet und keine Dienstprogramme außerhalb von Git selbst benötigt?

    – Andreas Spencer

    18. Juni 2021 um 11:47 Uhr

  • Mir selbst antworten – dies ist NICHT die kanonische Antwort, da sie nur in einem Repo funktioniert, das durch Klonen von der Fernbedienung erstellt wurde – nicht von einem Repo, das Sie erstellt und dann die Fernbedienung hinzugefügt haben git remote add und dazu geschoben.

    – Andreas Spencer

    18. Juni 2021 um 11:52 Uhr

  • (Ich stimme immer noch hoch, da dies die beste Antwort im wahrscheinlichen Anwendungsfall eines Skripts ist, bei dem Sie wissen, dass Sie das Repo von einer Fernbedienung geklont haben.)

    – Andreas Spencer

    18. Juni 2021 um 11:54 Uhr

  • Funktioniert bei mir nicht: Wenn ich wie in der Antwort ausgeführt werde, bekomme ich nur stdout origin/HEADund es gibt auch Fehler warning: ignoring dangling symref refs/remotes/origin/HEAD, fatal: ambiguous argument 'origin/HEAD': unknown revision or path not in the working tree.. Wenn ich an den Befehl a anhänge -- .es sagt warning: ignoring dangling symref refs/remotes/origin/HEAD, fatal: bad revision 'origin/HEAD'. Allerdings ist die git symbolic-ref Antwort Diese Antwort bezieht sich auf Werke für mich.

    – Hallo Engel

    8. August 2021 um 14:42 Uhr

Diese Frage ist etwas alt, aber falls jemand in letzter Zeit darauf stößt …

git remote show <remote_name> | awk '/HEAD branch/ {print $NF}'

Dadurch wird auch nur der Zweigname angezeigt, ohne Leerzeichen oder anderen Unsinn.

Ich speichere dies gerne mit ein paar Git-Aliassen (ich habe eine Reihe nützlicher Aliase wie diese):

upstream-name = !git remote | egrep -o '(upstream|origin)' | tail -1
head-branch = !git remote show $(git upstream-name) | awk '/HEAD branch/ {print $NF}'

Ich verwende “upstream” und “origin” fast 100% der Zeit als meine Fernbedienungen (“upstream”, wenn ich mit a Fork & Pull Workflow … was oft der Fall ist). Ihr Anwendungsfall benötigt die möglicherweise nicht upstream-name Alias, ich finde es nur nützlich.

Bisher scheint es keine Antwort zu geben, die kein Klonen erfordert

Dies erfordert git 2.8.0 oder neuer

$ git ls-remote --symref [email protected]:pre-commit/pre-commit.github.io HEAD
ref: refs/heads/real_master HEAD
e100a6a3c72b4e54f0d176f791dfd2dbd7eb5fa7    HEAD

  • Danke für eine nette Antwort. Ich habe awk hinzugefügt, um den Zweignamen zu übernehmen: git ls-remote --symref https://github.com/hnakamur/ltsvlog HEAD | awk '/^ref:/ {sub(/refs\/heads\//, "", $2); print $2}'

    – hnakamur

    27. Juli 2020 um 9:02 Uhr

  • Das ist eine nette Antwort, aber sie gibt Ihnen nur den aktuellen HEAD der Fernbedienung und keine Informationen darüber, welcher der Standardzweig ist.

    – Radon8472

    21. September 2022 um 8:00 Uhr

  • real_master Hier ist der Standardzweig

    – Antony Sottile

    21. September 2022 um 12:41 Uhr

Benutzeravatar von lsl
lsl

Da ist ein –kurz Option zu git symbolisch-ref. Also mein bevorzugter Befehl:

$ basename $(git symbolic-ref --short refs/remotes/origin/HEAD) 
master

  • Danke für eine nette Antwort. Ich habe awk hinzugefügt, um den Zweignamen zu übernehmen: git ls-remote --symref https://github.com/hnakamur/ltsvlog HEAD | awk '/^ref:/ {sub(/refs\/heads\//, "", $2); print $2}'

    – hnakamur

    27. Juli 2020 um 9:02 Uhr

  • Das ist eine nette Antwort, aber sie gibt Ihnen nur den aktuellen HEAD der Fernbedienung und keine Informationen darüber, welcher der Standardzweig ist.

    – Radon8472

    21. September 2022 um 8:00 Uhr

  • real_master Hier ist der Standardzweig

    – Antony Sottile

    21. September 2022 um 12:41 Uhr

Der folgende Befehl listet den HEAD-Zweig auf, unabhängig davon, wie Sie Ihre Fernbedienungen benannt haben:

git branch --remotes --list '*/HEAD'

Daraus können Sie den Standardzweig wie folgt extrahieren:

git branch -rl '*/HEAD' | rev | cut -d/ -f1 | rev

(unter Verwendung kurzer Varianten der git branch Argumente).

Wenn Ihre Shell das nicht hat rev Befehl können Sie verwenden awk stattdessen:

git branch -rl '*/HEAD' | awk -F/ '{print $NF}'

  • Ich arbeite irgendwo, dass stage wird als Stamm für die Entwicklung verwendet, und master wird für die Bereitstellung verwendet. Das gibt mir stagedas wollte ich – danke!

    – Rattenfänger

    27. Mai 2021 um 18:39 Uhr

  • Gibt für mich bash: rev: command not found und fatal: -a and -r options to 'git branch' do not make sense with a branch name

    – Radon8472

    21. September 2022 um 7:51 Uhr

  • @ Radon8472 Wenn Ihre Shell das nicht hat rev Befehl können Sie verwenden awk stattdessen: git branch -rl '*/HEAD' | awk -F/ '{print $NF}'

    – Henry

    22. September 2022 um 12:15 Uhr

  • @Henry das gibt fatal: -a and -r options to 'git branch' do not make sense with a branch name

    – Radon8472

    24. September 2022 um 6:31 Uhr

  • @ Radon8472 Woher kommt das -a Option kommen? Was erhalten Sie, wenn Sie nur den ersten Befehl ausführen: git branch -rl '*/HEAD' ?

    – Henry

    25. September 2022 um 23:02 Uhr

1441030cookie-checkWie bekomme ich den Standard-Git-Branch?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy

Contact - Terms and Conditions - Privacy Policy