git checkout refs/heads/master trennt HEAD

Ich habe einen lokalen Zweig “Master”, der einen Remote-Zweig “Origin/Master” verfolgt.

Wenn ich den Master wie folgt auschecke:

git checkout refs/heads/master

Am Ende habe ich einen abgetrennten KOPF:

Hinweis: Auschecken von ‘refs/heads/master’.

Sie befinden sich im Status „freistehender HEAD“. Sie können sich umsehen, experimentelle Änderungen vornehmen und sie festschreiben, und Sie können alle Festschreibungen, die Sie in diesem Zustand vornehmen, verwerfen, ohne dass dies Auswirkungen auf Zweige hat, indem Sie einen weiteren Checkout durchführen.

Natürlich könnte ich einfach “master” auschecken, aber das ist eine mehrdeutige Referenz. Ich möchte nur wissen, wie der “Git-Weg” einen Zweignamen eindeutig macht, ohne HEAD zu trennen.

Die Dokumentation für git checkout schweigt darüber, wie es sich wann verhält master ist nicht eindeutig. Wenn ich mir den Quellcode ansehe (ich habe schnell überflogen, also könnte ich falsch liegen), sieht es so aus git checkout geht davon aus, dass der angegebene Name (z. B. master) ist ein Verzweigungsname, bis festgestellt wird, dass kein Verweis vorhanden ist refs/heads/* für den Vornamen.

Der richtige Weg, einen Zweig auszuchecken, wenn die Revision mehrdeutig ist, besteht darin, das wegzulassen refs/heads/z.B, git checkout master.

Verzweigung vs. Revision

Beachten Sie, dass es einen feinen, aber wichtigen Unterschied zwischen der Angabe von a gibt Zweig und Angabe von a Revision (oder andere Objekt). Für Befehle und Optionen, die eine Revision (oder ein allgemeines Objekt) annehmen, geben Sie an master ist dasselbe wie spezifizieren refs/heads/master wenn nicht master ist nicht eindeutig. Es ist auch dasselbe wie spezifizieren master^0oder die SHA1, die master zeigt auf usw.

Für Befehle und Optionen, die eine Verzweigung nehmen (z. B. git branchoder der --branches Option zu Befehlen wie git log), Angabe master ist nicht dasselbe wie spezifizieren refs/heads/master. In diesen Fällen die vollständige Zeichenfolge refs/heads/master wird als Name der Verzweigung interpretiert, wodurch Git die benannte Referenz erstellt/untersucht/aktualisiert refs/heads/refs/heads/master Anstatt von refs/heads/master.

Das git checkout Befehl ist vielseitig, was praktisch ist, aber in Fällen wie Verwirrung stiften kann master vs. refs/heads/master. Wenn Sie angeben masterund ein Verweis namens refs/heads/master existiert, git checkout nehme an du meintest die master Zweig, nicht die Überarbeitung, die master zeigt auf. Wenn Sie angeben refs/heads/masterund ein Verweis namens refs/heads/refs/heads/master existiert dann nicht git checkout nehme an du meinst die Überarbeitung damit master zeigt auf, nicht auf einen benannten Zweig refs/heads/master (so erhalten Sie eine freistehende HEAD).

Auschecken des Nicht-Zweigs, wenn mehrdeutig

Wenn Sie sich einen anderen Ref ansehen möchten, dessen Kurzname ebenfalls lautet master (z. B. ein Tag namens master), müssen Sie den vollständigen Referenznamen buchstabieren (z. B. git checkout refs/tags/master) oder die Überarbeitung so buchstabieren, dass sie nicht als gültiger Zweigname interpretiert werden kann (z. B. git checkout master^0). Letzteres verursacht git checkout die in beschriebenen Disambiguierungsregeln zu befolgen git help revisions:

Wenn mehrdeutig, a <refname> wird disambiguiert, indem die erste Übereinstimmung in den folgenden Regeln genommen wird:

1. Wenn $GIT_DIR/<refname> existiert, das meinen Sie (dies ist normalerweise nur nützlich für HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD und CHERRY_PICK_HEAD);
2. Andernfalls, refs/<refname> wenn es existiert;
3. Andernfalls, refs/tags/<refname> wenn es existiert;
4. Andernfalls, refs/heads/<refname> wenn es existiert;
5. Andernfalls, refs/remotes/<refname> wenn es existiert;
6. Andernfalls, refs/remotes/<refname>/HEAD wenn es existiert.

Natürlich wird das Ergebnis ein freistehendes sein HEADaber das passiert immer, wenn Sie eine Nicht-Filiale auschecken.