Sie arbeiten fleißig an etwas und stellen fest, dass die Änderungen in diesen Dateien in Ordnung sind. Sie möchten sie nicht sehen, wenn Sie git diff ausführen, da Sie an anderen Dateien arbeiten und Änderungen an diesen Dateien ablenkend sind.

Jemand bittet Sie um einen Pull, und die Änderungen klingen vielversprechend.

Sie haben jedoch bereits den Index "beschmutzt" (d. h. Ihr Index stimmt nicht mit dem HEAD-Commit überein). Aber Sie wissen, dass der bevorstehende Pull frotz.c oder filfre.c nicht beeinflusst, also setzen Sie die Indexänderungen für diese beiden Dateien zurück. Ihre Änderungen im Arbeitsbaum bleiben erhalten.

Dann können Sie pullen und mergen, wobei die Änderungen in frotz.c und filfre.c weiterhin im Arbeitsbaum verbleiben.

Dies geschieht meistens, wenn Sie sich erinnern, dass das, was Sie gerade committet haben, unvollständig ist, oder Sie haben Ihren Commit-Nachricht falsch geschrieben, oder beides. Lässt den Arbeitsbaum so, wie er vor dem "Reset" war.

Nehmen Sie Korrekturen an den Arbeitsbaum-Dateien vor.

"reset" kopiert den alten Kopf nach .git/ORIG_HEAD; erstellen Sie den Commit neu, indem Sie mit seiner Log-Nachricht beginnen. Wenn Sie die Nachricht nicht weiter bearbeiten müssen, können Sie stattdessen die Option -C verwenden.

Sie haben einige Commits erstellt, erkennen aber, dass diese verfrüht für den master-Branch waren. Sie möchten sie in einem Topic-Branch weiter polieren, also erstellen Sie den Branch topic/wip ausgehend vom aktuellen HEAD.

Spulen Sie den master-Branch zurück, um diese drei Commits zu entfernen.

Wechseln Sie zum Branch topic/wip und arbeiten Sie weiter.

Die letzten drei Commits (HEAD, HEAD^ und HEAD~2) waren schlecht und Sie möchten sie nie wieder sehen. Tun Sie dies **nicht**, wenn Sie diese Commits bereits jemand anderem gegeben haben. (Siehe den Abschnitt "RECOVERING FROM UPSTREAM REBASE" in git-rebase[1] für die Auswirkungen davon.)

Versuche, vom Upstream zu aktualisieren, führte zu vielen Konflikten; Sie waren im Moment nicht bereit, viel Zeit für das Mergen aufzuwenden, also beschlossen Sie, dies später zu tun.

"pull" hat keinen Merge-Commit erstellt, also bereinigt git reset --hard, was ein Synonym für git reset --hard HEAD ist, das Durcheinander aus der Indexdatei und dem Arbeitsbaum.

Führen Sie einen Topic-Branch in den aktuellen Branch zusammen, was zu einem Fast-Forward führte.

Aber Sie haben beschlossen, dass der Topic-Branch noch nicht für die öffentliche Nutzung bereit ist. "pull" oder "merge" hinterlässt immer die ursprüngliche Spitze des aktuellen Branches in ORIG_HEAD, also bringt das harte Zurücksetzen darauf Ihre Indexdatei und den Arbeitsbaum in diesen Zustand zurück und setzt die Spitze des Branches auf diesen Commit zurück.

Selbst wenn Sie lokale Änderungen in Ihrem Arbeitsbaum haben, können Sie git pull sicher ausführen, wenn Sie wissen, dass die Änderung im anderen Branch sich nicht mit ihnen überschneidet.

Nachdem Sie das Ergebnis des Merges geprüft haben, stellen Sie möglicherweise fest, dass die Änderung im anderen Branch unbefriedigend ist. Wenn Sie git reset --hard ORIG_HEAD ausführen, gelangen Sie zurück zu dem Zustand, in dem Sie waren, aber es werden Ihre lokalen Änderungen verworfen, was Sie nicht wollen. git reset --merge behält Ihre lokalen Änderungen.

Dieser Commit wird verworfen, daher ist eine Wegwerf-Log-Nachricht in Ordnung.

Dies entfernt den *WIP*-Commit aus der Commit-Historie und versetzt Ihren Arbeitsbaum in den Zustand kurz vor der Erstellung dieses Snapshots.

An diesem Punkt enthält die Indexdatei immer noch alle WIP-Änderungen, die Sie als *Snapshot WIP* committet haben. Dies aktualisiert den Index, um Ihre WIP-Dateien als uncommittet anzuzeigen.

Dies entfernt die Datei aus dem Index, während sie im Arbeitsverzeichnis verbleibt.

Dies committet alle anderen Änderungen im Index.

Fügt die Datei erneut zum Index hinzu.

Dies committet Ihre ersten Bearbeitungen im Branch branch1.

Im Idealfall hätten Sie erkannt, dass der frühere Commit nicht zum neuen Thema gehörte, als Sie branch2 erstellt und zu ihm gewechselt haben (d. h. git switch -c branch2 start), aber niemand ist perfekt.

Aber Sie können reset --keep verwenden, um den unerwünschten Commit zu entfernen, nachdem Sie zu branch2 gewechselt haben.

Zuerst setzen wir die Historie um einen Commit zurück, damit wir den ursprünglichen Commit entfernen, aber den Arbeitsbaum mit allen Änderungen belassen. Die Option -N stellt sicher, dass neue Dateien, die mit HEAD hinzugefügt wurden, weiterhin markiert sind, sodass git add -p sie findet.

Als Nächstes wählen wir interaktiv Diff-Hunks zum Hinzufügen aus, indem wir die Funktionalität git add -p verwenden. Dies wird Sie nacheinander nach jedem Diff-Hunk fragen und Sie können einfache Befehle wie "Ja, diesen einschließen", "Nein, diesen nicht einschließen" oder sogar die sehr mächtige "Bearbeiten"-Funktion verwenden.

Sobald Sie mit den Hunks, die Sie aufnehmen möchten, zufrieden sind, sollten Sie überprüfen, was für den ersten Commit vorbereitet wurde, indem Sie git diff --cached verwenden. Dies zeigt alle Änderungen an, die in den Index verschoben wurden und kurz vor dem Commit stehen.

Als Nächstes committen Sie die im Index gespeicherten Änderungen. Die Option -c gibt an, dass die Commit-Nachricht aus der ursprünglichen Nachricht vorab ausgefüllt werden soll, mit der Sie im ersten Commit begonnen haben. Dies ist hilfreich, um erneutes Tippen zu vermeiden. HEAD@{1} ist eine spezielle Notation für den Commit, an dem HEAD vor dem ursprünglichen Reset-Commit (1 Änderung zuvor) war. Siehe git-reflog[1] für weitere Details. Sie können auch jede andere gültige Commit-Referenz verwenden.

Sie können die Schritte 2-4 mehrmals wiederholen, um den ursprünglichen Code in eine beliebige Anzahl von Commits aufzuteilen.

Nun haben Sie viele der Änderungen in eigene Commits aufgeteilt und verwenden möglicherweise nicht mehr den Patch-Modus von git add, um alle verbleibenden uncommitteten Änderungen auszuwählen.

Überprüfen Sie noch einmal, ob Sie alles aufgenommen haben, was Sie wollten. Möglicherweise möchten Sie auch überprüfen, ob git diff keine verbleibenden Änderungen anzeigt, die später committet werden sollen.

Und schließlich erstellen Sie den endgültigen Commit.