Verwirrt durch Git-Checkout

Ich bin neu bei Git und versuche, mich mit der Funktionsweise von Branches vertraut zu machen. Laut Dokumentation git checkout

Aktualisiert Dateien in der Arbeitsstruktur, sodass sie mit der Version im Index oder der angegebenen Struktur übereinstimmen. Wenn >keine Pfade angegeben sind, aktualisiert git checkout auch HEAD, um den angegebenen Zweig als >aktuellen Zweig festzulegen.

So wie ich es verstehe, sollten sich die Dateien in meinem Verzeichnis, in dem ich arbeite (die Datei, in der ich die Git-Init durchgeführt habe), entsprechend dem Zweig ändern, in dem ich mich befinde. Ich bin verwirrt, weil dies nicht passiert, wenn ich zwischen Zweigen wechsle. Änderungen, an denen ich gearbeitet habe, bevor ich den Zweig gewechselt habe, sind in dem Zweig vorhanden, zu dem ich gewechselt habe. Mache ich etwas falsch oder funktioniert Git Checkout nicht auf diese Weise und ich missverstehe nur die Dokumentation?

Diese Verwirrung wird von Git 2.23 anerkannt.
Git 2.23 (Q3 2019) wird ersetzen git checkout mit zwei neuen Befehlen:

• git switch
• git restore (hier abgebildet)

Sehen Commit 97ed685, Übertrage d16dc42, begehen Sie bcba406 (20. Juni 2019), begehen 4e43b7f, Festschreiben 1235875, 80f537f begehen, fc991b4 übergeben, begehen 75f4c7c, Commit 4df3ec6, Commit 2f0896e, begehe a5e5f39, Commit 3a733ce, e3ddd3b übergeben, 183fb44 begehen, Festschreiben 4058199, a6cfb9b begehen, be8ed50 übergeben, c9c935f übergeben, Commit 46e91b6 (25. April 2019) und 328c6cb übergeben (29. März 2019) von Nguyễn Thái Ngọc Duy (pclouds).
^{(Zusammengeführt von Junio ​​C. Hamano — gitster — in f496b06 übergeben09.07.2019)}

checkout: Teil davon in neuen Befehl aufteilen ‘switch‘

“git checkout” Zu viele Dinge zu tun, ist für viele Benutzer eine Quelle der Verwirrung (und es beißt manchmal sogar alte Hasen).

Um dies zu beheben, wird der Befehl in zwei neue aufgeteilt: switch und restore. Die gute alte“git checkout“-Befehl ist immer noch da und wird es sein, bis alle (oder die meisten Benutzer) ihn satt haben.

Und:

Schalter: Ablehnen, wenn eine Operation im Gange ist

Wenn Sie nicht wissen, was Sie tun, kann es verwirrend sein, zu einem anderen Zweig zu wechseln, um etwas zu tun, und dann zurück zu wechseln. Schlimmer noch, Sie könnten sogar vergessen, dass Sie mitten in etwas sind. Bis du es merkst, hast du vielleicht eine Menge Arbeit geleistet und es wird schwieriger, zurück zu gehen.

Eine neue Möglichkeit --ignore-in-progress wurde in Betracht gezogen, aber fallen gelassen, weil nicht genau klar war, was passieren sollte.
Manchmal können Sie wegschalten und sicher zurückkehren und den Betrieb wieder aufnehmen. Manchmal nicht.
Und das git-checkout Verhalten ist automatisch Clear Merge/Revert/Cherry-Pick, was es noch etwas verwirrender macht.
Siehe diese Diskussion.

Wir werden diese Option möglicherweise in Zukunft erneut prüfen und hinzufügen.
Aber jetzt gehen Sie auf Nummer sicher und lassen Sie es nicht zu (Sie können diese Prüfung nicht einmal überspringen mit --force).
Dem Benutzer wird empfohlen, den Vorgang selbst abzubrechen (und hoffentlich die Konsequenzen zu berücksichtigen, nicht blind den Befehl einzugeben) oder einen separaten Arbeitsbaum zu erstellen, anstatt zu wechseln.

Die dritte Option ist die gute alte “git checkout“, wird aber nicht erwähnt.

Sehen git switch Manpage

BEZEICHNUNG

Wechseln Sie zu einem bestimmten Zweig.
Der Arbeitsbaum und der Index werden aktualisiert, um dem Zweig zu entsprechen.
Alle neuen Commits werden an der Spitze dieses Zweigs hinzugefügt.

Optional kann mit beiden ein neuer Zweig erstellt werden -c, -Cautomatisch von einem entfernten Zweig mit demselben Namen (siehe --guess), oder lösen Sie den Arbeitsbaum von einem beliebigen Zweig mit --detachzusammen mit dem Umschalten.

Das Wechseln von Zweigen erfordert keinen sauberen Index und Arbeitsbaum (dh keine Unterschiede im Vergleich zu HEAD).
Die Operation wird jedoch abgebrochen, wenn die Operation zum Verlust lokaler Änderungen führt, sofern nicht anders mit angegeben --discard-changes oder --merge.

BEISPIELE

Der folgende Befehl wechselt zum “main” sich verzeigen:

$ git switch main

Nachdem Sie im falschen Zweig gearbeitet haben, wird zum richtigen Zweig gewechselt mit:

$ git switch mytopic

Allerdings ist Ihr “falscher” Zweig und Ihr richtiger “mytopic” Zweig kann sich in Dateien unterscheiden, die Sie lokal geändert haben, in diesem Fall würde der obige Schalter wie folgt fehlschlagen:

$ git switch mytopic
error: You have local changes to 'frotz'; not switching branches.

Sie können die geben -m Flag an den Befehl, der eine Drei-Wege-Zusammenführung versuchen würde:

$ git switch -m mytopic
Auto-merging frotz

Nach dieser dreifachen Zusammenführung sind die lokalen Änderungen nicht in Ihrer Indexdatei registriert, also git diff würde Ihnen zeigen, welche Änderungen Sie seit der Spitze des neuen Zweigs vorgenommen haben.

Zum vorherigen Zweig zurückwechseln, bevor wir gewechselt haben mytopic (dh “main” sich verzeigen):

$ git switch -

Sie können aus jedem Commit einen neuen Branch erzeugen.
Wechseln Sie beispielsweise zu “HEAD~3” und Zweig erstellen “fixup“:

$ git switch -c fixup HEAD~3
Switched to a new branch 'fixup'

Wenn Sie einen neuen Branch von einem Remote-Branch mit demselben Namen starten möchten:

$ git switch new-topic
Branch 'new-topic' set up to track remote branch 'new-topic' from 'origin'
Switched to a new branch 'new-topic'

Commit auschecken HEAD~3 für temporäre Inspektion oder Experiment, ohne einen neuen Zweig zu erstellen:

$ git switch --detach HEAD~3
HEAD is now at 9fc9555312 Merge branch 'cc/shared-index-permbits'

Wenn sich herausstellt, dass das, was Sie getan haben, es wert ist, behalten zu werden, können Sie jederzeit einen neuen Namen dafür erstellen (ohne wegzuschalten):

$ git switch -c good-surprises

Beachten Sie die Fehlermeldungen, die “git switch” erwähnt die Option, einen neuen Zweig zu erstellen, “-b/-B” Optionen wurden angezeigt, wobei “-c/-C“Optionen sein sollte, was mit Git 2.27 (Q2 2020) korrigiert wurde.

Sehen begehen 7c16ef7 (30.04.2020) von Denton Liu (Denton-L).
^{(Zusammengeführt von Junio ​​C. Hamano — gitster — in f4675f3 übergeben08. Mai 2020)}

switch: Fehler und Kommentare im Zusammenhang mit -c und -C behoben

^{Berichtet von: Robert Simpson
Unterzeichnet von: Denton Liu
Bewertet von: Taylor Blau}

Im d787d311db (“checkout: Teil davon in neuen Befehl ‘switch’ aufteilen”, 2019-03-29, Git v2.23.0-rc0 — verschmelzen gelistet in Charge Nr. 4), der git switch Befehl wurde durch Extrahieren der gemeinsamen Funktionalität von erstellt cmd_checkout() in checkout_main().

Allerdings hinein b7b5fce270 (“switch: bessere Namen für -b und -B“, 29.03.2019, Git v2.23.0-rc0 — verschmelzen gelistet in Charge Nr. 4), die Optionen zum Erstellen von Zweigen und Erzwingen von ‘switch‘ wurden geändert in -c und -Cbzw.

Infolgedessen werden Fehlermeldungen und Kommentare angezeigt, auf die zuvor verwiesen wurde -b und -B wurde ungültig für git switch.

Für Fehlermeldungen, die sich auf -b und -Bverwenden Sie stattdessen eine Formatzeichenfolge, damit -c und -C wann gedruckt werden kann git switch wird aufgerufen.

Git hat dieses allgemeine Problem, etwa acht oder zehn verschiedene Dinge in einen Befehl zu packen. Hinweis: Git 2.23 teilt einige davon auf – hilfreich, um sicher zu sein, aber auch eine sehr große Änderung. (Sollte Git 2.23 Git 3.0 heißen? Git 2.0 hat das Verhalten von geändert git addwas mir graduell ähnlich erscheint.) Siehe auch die Antwort von VonC.

git checkout kann aktualisieren Sie den Arbeitsbaum und tut dies normalerweise.

Es kann ändern wo HEAD Punkte, und manchmal tut es, manchmal nicht.

Es kann Überschreiben Sie Ihre Arbeit in einer Datei, falls Sie die Datei zurücksetzen und Ihre Arbeit rückgängig machen möchten. Oder es kann Weigern Sie sich, die Arbeit zu überschreiben, die Sie an einer Datei vorgenommen haben, und lassen Sie sie unverändert, während Sie sie ändern HEADoder nicht Ändern HEAD.

Die Sache an all dem ist, dass es, obwohl es bemerkenswert schwer zu beschreiben ist, eigentlich alles Sinn macht, und nach einer Weile gewöhnt man sich daran und stellt fest, dass der eine Befehl meistens das tut, was man meint. (Das “meistens” kann natürlich ein Problem sein ….)

Wie auch immer, das besondere Verhalten, das Sie sehen, ist ein absichtliches Merkmal. Nehmen wir an, Sie beginnen mit einem Ast mainwie es die meisten Repositories tun:

$ git clone ...
$ git branch
* main
$

An diesem Punkt können Sie einige Dateien bearbeiten, etwas arbeiten und erst dann feststellen: „gah! Ich wollte das auf Zweig machen develop!”¹

An dieser Stelle können Sie mit Git zu einem Branch wechseln (oder einen Branch erstellen). develop, Behalten Sie Ihre Änderungen beiunter einer Bedingung: das Umschalten auf develop erfordert nicht, sie auszulöschen. Angenommen, Sie haben die Datei geändert f1 und eine neue erstellt f2und Sie möchten jetzt einen lokalen Zweig erstellen und auschecken develop das sollte beginnen und automatisch “tracken”,² origin/develop:

$ git checkout develop 

(In sehr alten Git-Versionen müssen Sie dies buchstabieren git checkout -b develop --track origin/develop).

Sagen wir auch diese Datei f1 ist das gleiche an den Spitzen der Zweige main und Zweig develop.³ Was das bedeutet, um zu sagen, ist, dass es kann Führen Sie diese Überprüfung durch, da die Datei nicht geändert werden muss f1damit es Ihre bestehenden Änderungen belassen kann f1 an Ort und Stelle.

Wenn Datei f2 ist Auch in beiden Commits gleich ist, oder (wie in diesem Fall) in keinem existiert, dann werden keine Dateien geclobbed, und git checkout erstellt Ihre neue lokale Niederlassung developindem der Arbeitsbaum entsprechend geändert wird origin/develop nach Bedarf – und das beinhaltet nicht das Modifizieren f1noch entfernen f2sodass Ihre bisherige Arbeit intakt bleibt.

Auf diese Weise können Sie Ihre neuen Änderungen an Ihre lokale Datei übertragen develop.

(Wenn Sie auf Fälle stoßen, in denen Git tut Ihre Änderungen rückgängig machen müssen, sie aber trotzdem in einen anderen Zweig “verschieben” möchten, ist der übliche Trick, die zu verwenden git stash Skript. Das klingt nach einer einfachen Sache, und git stash ist oft einfach zu bedienen, aber unter der Decke ist es eigentlich ein ziemlich kompliziertes kleines Biest. Machen Sie sich darüber jedoch keine Sorgen, bis Sie es brauchen.)

¹Das passiert mir die ganze Zeit. Oft möchte ich einen neuen Non-Tracking-Branch erstellen, was etwas einfacher ist, als zu einem bestehenden Branch zu wechseln, aber das Prinzip gilt immer noch.

²Diese automatische Nachverfolgung ermöglicht es Ihnen, Änderungen, die andere Personen vorgenommen haben, einfacher einzubringen: sobald Git sie aufgreift git fetchGit informiert Sie über die Änderungen dieser anderen Personen und lässt Sie verwenden git merge oder git rebase um Ihre Änderungen mit ihren zu kombinieren, ohne viel zusätzliches Herumstöbern, um herauszufinden, wessen Änderungen wohin gehören.

³Da Sie neu bei Git sind, gibt es Konzepte wie die Unterscheidung zwischen „der Spitze eines Zweigs“, bei dem es sich um ein bestimmtes Commit handelt, und „dem Zweig“, der eigentlich mehrdeutig ist – es gibt Verzweigungen Etikettenund dann gibt es Zweig Strukturen der vom Commit-Baum gebildet wird – ist etwas anderes, das Sie meistens für eine Weile ignorieren sollten. Die Hauptsache ist, dass es eine spezielle Datei im Git-Repository mit dem Namen HEADund in diese spezielle Datei schreibt git die Zeichenfolge ref: refs/heads/main oder ref: refs/heads/develop, um zu verfolgen, in welchem ​​Zweig Sie sich befinden. Damit git checkout X werde schreiben ref: refs/heads/X hinein HEAD sobald es auf Verzweigung umschaltet X.

In der Zwischenzeit teilt ein anderer Satz spezieller Dateien im Repository Git diesen Zweig mit main bezieht sich auf einen dieser großen hässlichen SHA-1 wie c06f8d11b75e28328cdc809397eddd768ebeb533. Dies ist die “Spitze” der Branche main. Wenn Sie ein neues Commit machen mainerstellt Git den neuen Commit „Eins nach dem alten Tipp“, schreibt dann den neuen SHA-1 in die Branch-Dateien, damit main ist jetzt Ihr neues Commit.

Die genauen Details sind nicht so wichtig wie die Idee, dass Neu Commits setzen einfach die Verzweigungsspitze fort.

Wenn Sie einen Zweig erstellen, erhält dieser Zweig automatisch die Dateien des Zweigs, in dem Sie sich befanden, als Sie diesen neuen Zweig erstellt haben.

Nehmen wir an, Sie sind dabei main Branche und Sie möchten eine erstellen develop sich verzeigen. Alles zusammen sollte so aussehen:

git checkout -b develop    # create and switch to develop branch
touch text.txt             # create a file
git add .                  # add file to staging area
git commit -m "adding text.txt" 
git checkout main

Und dann wirst du es nicht sehen text.txt seit du drin bist main.