-
1. Erste Schritte
-
2. Git Grundlagen
-
3. Git Branching
- 3.1 Branches auf einen Blick
- 3.2 Einfaches Branching und Merging
- 3.3 Branch-Management
- 3.4 Branching-Workflows
- 3.5 Remote-Branches
- 3.6 Rebasing
- 3.7 Zusammenfassung
-
4. Git auf dem Server
- 4.1 Die Protokolle
- 4.2 Git auf einem Server einrichten
- 4.3 Erstellung eines SSH-Public-Keys
- 4.4 Einrichten des Servers
- 4.5 Git-Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Von Drittanbietern gehostete Optionen
- 4.10 Zusammenfassung
-
5. Verteiltes Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisions-Auswahl
- 7.2 Interaktives Stagen
- 7.3 Stashen und Bereinigen
- 7.4 Ihre Arbeit signieren
- 7.5 Suchen
- 7.6 Den Verlauf umschreiben
- 7.7 Reset entzaubert
- 7.8 Fortgeschrittenes Merging
- 7.9 Rerere
- 7.10 Debuggen mit Git
- 7.11 Submodule
- 7.12 Bundling
- 7.13 Replace (Ersetzen)
- 7.14 Anmeldeinformationen speichern
- 7.15 Zusammenfassung
-
8. Git einrichten
- 8.1 Git Konfiguration
- 8.2 Git-Attribute
- 8.3 Git Hooks
- 8.4 Beispiel für Git-forcierte Regeln
- 8.5 Zusammenfassung
-
9. Git und andere Systeme
- 9.1 Git als Client
- 9.2 Migration zu Git
- 9.3 Zusammenfassung
-
10. Git Interna
-
A1. Anhang A: Git in anderen Umgebungen
- A1.1 Grafische Schnittstellen
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Zusammenfassung
-
A2. Anhang B: Git in Ihre Anwendungen einbetten
- A2.1 Die Git-Kommandozeile
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Anhang C: Git Kommandos
- A3.1 Setup und Konfiguration
- A3.2 Projekte importieren und erstellen
- A3.3 Einfache Snapshot-Funktionen
- A3.4 Branching und Merging
- A3.5 Projekte gemeinsam nutzen und aktualisieren
- A3.6 Kontrollieren und Vergleichen
- A3.7 Debugging
- A3.8 Patchen bzw. Fehlerkorrektur
- A3.9 E-mails
- A3.10 Externe Systeme
- A3.11 Administration
- A3.12 Basisbefehle
2.4 Git Grundlagen - Ungewollte Änderungen rückgängig machen
Ungewollte Änderungen rückgängig machen
Zu jeder Zeit können Sie eine Änderung rückgängig machen. Hier werden wir einige grundlegende Werkzeuge besprechen, die zum Widerrufen von gemachten Änderungen dienen. Seien Sie vorsichtig, denn man kann nicht immer alle diese Annullierungen rückgängig machen. Das ist einer der wenigen Bereiche in Git, in denen Sie etwas Arbeit verlieren könnten, wenn Sie etwas falsch machen.
Eines der häufigsten Undos tritt auf, wenn Sie zu früh committen und möglicherweise vergessen haben, einige Dateien hinzuzufügen, oder wenn Sie Ihre Commit-Nachricht durcheinander bringen.
Wenn Sie den Commit erneut ausführen möchten, nehmen Sie die zusätzlichen Änderungen vor, die Sie vergessen haben, stellen diese bereit (engl. stage) und committen diese erneut mit der Option --amend
:
$ git commit --amend
Dieser Befehl übernimmt Ihre Staging-Area und verwendet sie für den Commit. Wenn Sie seit Ihrem letzten Commit keine Änderungen vorgenommen haben (z.B. Sie führen diesen Befehl unmittelbar nach Ihrem vorherigen Commit aus), dann sieht Ihr Snapshot genau gleich aus; Sie ändern nur Ihre Commit-Nachricht.
Der gleiche Commit-Message-Editor wird aufgerufen, enthält aber bereits die Nachricht Ihres vorherigen Commits. Sie können die Nachricht wie gewohnt bearbeiten, aber sie überschreibt den vorherigen Commit.
Wenn Sie zum Beispiel die Änderungen in einer Datei, die Sie zu dieser Übertragung hinzufügen wollten, vergessen haben, können Sie etwas Ähnliches durchführen:
$ git commit -m 'Initial commit'
$ git add forgotten_file
$ git commit --amend
Sie erhalten am Ende einen einzigen Commit – der zweite Commit ersetzt die Ergebnisse des ersten.
Anmerkung
|
Es ist wichtig zu verstehen, dass, wenn Sie Ihren letzten Commit ändern, Sie ihn weniger reparieren, als ihn komplett durch einen neuen, verbesserten Commit ersetzen. Der alte Commit wird aus dem Weg geräumt und der neue Commit an seine Stelle gesetzt. Tatsächlich ist es so, als ob der letzte Commit nie stattgefunden hätte und er nicht mehr in Ihrem Repository-Verlauf auftaucht. Der naheliegendste Nutzen für die Änderung von Commits besteht darin, kleine Verbesserungen an Ihrem letzten Commit vorzunehmen, ohne Ihren Repository-Verlauf mit Commit-Nachrichten der Form „Ups, vergessen, eine Datei hinzuzufügen“ oder „Verdammt, einen Tippfehler im letzten Commit behoben“ zu überladen. |
Anmerkung
|
Ändern Sie nur lokale Commits, die noch nicht gepusht wurden. Das Ändern zuvor übertragener Commits und das forcierte pushen des Branches verursacht Probleme bei ihren Mitstreitern. Weitere Informationen darüber, was dabei passiert und wie Sie es wieder gerade ziehen können, wenn Sie sich auf der Empfängerseite befinden, finden Sie unter Die Gefahren des Rebasing. |
Eine Datei aus der Staging-Area entfernen
Die nächsten beiden Abschnitte erläutern, wie Sie mit Ihrer Staging-Area und den Änderungen des Arbeitsverzeichnisses arbeiten.
Der angenehme Nebeneffekt ist, dass der Befehl, mit dem Sie den Zustand dieser beiden Bereiche bestimmen, Sie auch daran erinnert, wie Sie Änderungen an ihnen rückgängig machen können.
Nehmen wir zum Beispiel an, Sie haben zwei Dateien geändert und möchten sie als zwei separate Änderungen übertragen, aber Sie geben versehentlich git add *
ein und stellen sie dann beide in der Staging-Area bereit.
Wie können Sie eine der beiden aus der Staging-Area entfernen?
Der Befehl git status
meldet:
$ git add *
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
modified: CONTRIBUTING.md
Direkt unter dem Text „Changes to be committed“, steht, dass man git reset HEAD <file>…
verwenden soll, um die Staging-Area zu entleeren.
Lassen Sie uns also diesem Rat folgen und die Datei CONTRIBUTING.md
aus der Staging-Area entfernen:
$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
Der Befehl klingt etwas merkwürdig, aber er funktioniert.
Die Datei CONTRIBUTING.md
wurde modifiziert, aber erneut im Status unstaged.
Anmerkung
|
Es ist wahr, dass |
Im Moment ist dieser Aufruf alles, was Sie über den Befehl git reset
wissen müssen.
Wir werden viel ausführlicher darauf eingehen, was reset
bewirkt und wie man es beherrscht, um wirklich interessante Aufgaben zu erledigen, siehe Kapitel 7 Git Reset.
Änderung in einer modifizierten Datei zurücknehmen
Was ist, wenn Sie feststellen, dass Sie Ihre Änderungen an der Datei CONTRIBUTING.md
nicht behalten wollen?
Wie können Sie sie leicht wieder ändern – sie wieder so zurücksetzen, wie sie beim letzten Commit ausgesehen hat (oder anfänglich geklont wurde, oder wie auch immer Sie sie in Ihr Arbeitsverzeichnis bekommen haben)?
Glücklicherweise sagt Ihnen git status
auch, wie Sie das machen können.
Im letzten Beispiel sieht die Unstaged-Area so aus:
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
Sie erklärt Ihnen ziemlich eindeutig, wie Sie die von Ihnen vorgenommenen Änderungen verwerfen können. Lassen Sie uns machen, was da steht:
$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
Sie können erkennen, dass die Änderungen rückgängig gemacht wurden.
Wichtig
|
Es ist sehr wichtig zu begreifen, dass |
Wenn Sie die Änderungen, die Sie an dieser Datei gemacht haben, beibehalten möchten, sie aber vorerst aus dem Weg räumen möchten, sollten wir das Stashing und Branching in Kapitel 3 – Git Branching durchgehen; das sind im Allgemeinen die besseren Methoden, um das zu erledigen.
Denken Sie daran, dass alles, was in Git committet wird, fast immer wiederhergestellt werden kann.
Sogar Commits, die auf gelöschten Branches lagen oder Commits, die mit einem --amend
Commit überschrieben wurden, können wiederhergestellt werden (siehe Kapitel 10 Daten-Rettung für das Wiederherstellen der Daten).
Allerdings wird alles, was Sie verloren haben und das nie committet wurde, wahrscheinlich nie wieder gesehen werden.
Änderungen Rückgängigmachen mit git restore
Git Version 2.23.0 führte einen neuen Befehl ein: git restore
.
Es ist im Grunde eine Alternative zu git reset
, die wir gerade behandelt haben.
Ab Git Version 2.23.0 verwendet Git für viele Rückgängig-Vorgänge git restore
anstelle von git reset
.
Lassen Sie uns unsere Schritte zurückverfolgen und die Dinge mit git restore
anstelle von git reset
rückgängig machen.
Unstagen einer staged Datei mit git restore
Die nächsten beiden Abschnitte zeigen, wie Sie an Änderungen in Ihrem Staging-Bereich und im Arbeitsverzeichnisses mit git restore
arbeiten.
Das Schöne daran ist, dass der Befehl, mit dem Sie den Status dieser beiden Bereiche bestimmen, Ihnen auch zeigt, wie Sie Änderungen an ihnen rückgängig machen können.
Angenommen, Sie haben zwei Dateien geändert und möchten sie als zwei separate Änderungen festschreiben. Sie geben jedoch versehentlich git add *
ein und stellen beide bereit.
Wie können sie einen der beiden wieder unstagen?
Der Befehl git status
zeigt es ihnen:
$ git add *
$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: CONTRIBUTING.md
renamed: README.md -> README
Direkt unter dem Text „Changes to be committed“ steht git restore --staged <file> …
zum unstagen.
Verwenden wir diesen Rat, um die Datei CONTRIBUTING.md
zu unstagen:
$ git restore --staged CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
renamed: README.md -> README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
Die Datei CONTRIBUTING.md
ist geändert aber wieder unstaged.
Rückgängig machen einer geänderten Datei mit git restore
Was ist, wenn Sie feststellen, dass Sie Ihre Änderungen an der Datei CONTRIBUTING.md
nicht beibehalten möchten?
Wie können Sie sie einfach rückgängig machen — sprich, sie so zurücksetzen, wie sie aussah, als Sie sie zuletzt committet haben (oder ursprünglich geklont haben oder wie auch immer Sie es in Ihr Arbeitsverzeichnis aufgenommen haben)?
Glücklicherweise sagt Ihnen git status
wiederum, wie das geht.
In der letzten Beispielausgabe sieht der unstaged Bereich folgendermaßen aus:
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
Es zeigt Ihnen ziemlich explizit, wie Sie die vorgenommenen Änderungen verwerfen können. Lassen Sie uns das tun:
$ git restore CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
renamed: README.md -> README
Wichtig
|
Es ist wichtig zu verstehen, dass |