Dutzende animierte Bilder zeigen Ihnen, wie Git funktioniert

git merge, git rebase, git reset, git revert, git fetch, git pull, git reflog ... Wissen Sie, welche Aufgaben diese Git-Befehle ausführen? Wenn Sie immer noch verwirrt sind, sollten Sie diesen Artikel nicht verpassen. In diesem Artikel stellt Lydia Hallie, eine 21-jährige Softwareberaterin, die mit JavaScript, TypeScript, GraphQL, Serverless, AWS, Docker und Golang vertraut ist, intuitiv den Arbeitsprozess dieser häufig verwendeten Git-Befehle in Form von Animationen vor. dafür sorgen, dass Sie sie nie vergessen werden.

Obwohl Git ein sehr leistungsfähiges Werkzeug ist, würden die meisten Leute mir zustimmen, wenn ich sagen würde, dass die Verwendung von Git ein Albtraum ist. Wenn ich mit Git arbeite, finde ich es sehr hilfreich, es in meinem Kopf zu visualisieren: Wie interagieren diese Zweige, wenn ich einen bestimmten Befehl ausführe, und wie wirkt sich das auf den Verlauf aus? Warum weinen meine Kollegen, wenn ich einen harten Neustart des Masters durchführe, einen Push zum ursprünglichen Zweig erzwinge und unseren .git-Ordner rimraf?

Ich dachte, das Erstellen visueller Beispiele für einige der am häufigsten verwendeten und nützlichsten Git-Befehle wäre ein perfekter Anwendungsfall! Viele der Befehle, die ich im Folgenden beschreibe, verfügen über optionale Parameter – Sie können diese Parameter verwenden, um das Verhalten des entsprechenden Befehls zu ändern. Und mein Beispiel deckt nur das Standardverhalten des Befehls ab und fügt keine (oder zu viele) optionale Konfiguration hinzu!

Merge

Es ist praktisch, mehrere Zweige zu haben, um verschiedene neue Änderungen voneinander zu isolieren und auch um sicherzustellen, dass Sie nicht versehentlich unbeabsichtigte Änderungen am Produktionscode vornehmen. Permissive oder fehlerhafte Codeänderungen . Aber sobald diese Änderungen genehmigt sind, müssen wir sie in unserem Produktionszweig bereitstellen!

Eine Möglichkeit, Änderungen von einem Zweig in einen anderen zu integrieren, besteht darin, einen Git-Merge durchzuführen. Git kann zwei Arten von Zusammenführungen durchführen: Fast-Forward und No-Fast-Forward. Möglicherweise können Sie den Unterschied jetzt nicht erkennen, aber werfen wir einen Blick auf die Unterschiede.

Fast-Forward (—ff)

Fast-Forward-Merge kann durchgeführt werden, wenn der aktuelle Zweig im Vergleich zu dem Zweig, den wir zusammenführen möchten, keine zusätzlichen Commits hat. Git ist faul und wird zuerst die einfachste Option ausprobieren: Schnellvorlauf! Bei dieser Art der Zusammenführung werden keine neuen Commits erstellt, sondern die Commits des Zweigs, den wir zusammenführen, werden direkt mit dem aktuellen Zweig zusammengeführt.

Perfekt! Jetzt werden alle Änderungen, die wir am Dev-Zweig vorgenommen haben, im Master-Zweig zusammengeführt. Was bedeutet also kein schneller Vorlauf?

No-Fast-Forward (—no-ff)

Wenn Ihr aktueller Zweig im Vergleich zu dem Zweig, den Sie zusammenführen möchten, keine Commits hat, ist das in Ordnung, aber sehr traurig Die Realität sieht selten so aus! Wenn wir Änderungen am aktuellen Zweig festschreiben, die sich nicht in dem Zweig befinden, den wir zusammenführen möchten, führt Git eine Zusammenführung ohne schnellen Vorlauf durch.

Beim Zusammenführen mit No-Fast-Forward erstellt Git ein neues Zusammenführungs-Commit für den aktuell aktiven Zweig. Der übergeordnete Commit dieses Commits zeigt auf diesen aktiven Zweig und auch auf den Zweig, den wir zusammenführen möchten!

Keine große Sache, perfekte Zusammenführung! Jetzt werden alle Änderungen, die wir am Dev-Zweig vorgenommen haben, im Master-Zweig zusammengeführt.

Konflikte zusammenführen

Während Git ziemlich gut darin ist, zu entscheiden, wie Zweige zusammengeführt und Änderungen an Dateien hinzugefügt werden, trifft es diese Entscheidung nicht immer ganz alleine. Wenn die beiden Zweige, die wir zusammenführen möchten, unterschiedliche Änderungen an derselben Codezeile in derselben Datei aufweisen oder ein Zweig eine Datei löscht und der andere Zweig die Datei ändert, weiß Git nicht, was er auswählen soll.

In diesem Fall fragt Git Sie, welche Option Sie behalten möchten? Nehmen wir an, dass wir in beiden Zweigen die erste Zeile von README.md bearbeiten.

Wenn wir „dev“ mit „master“ zusammenführen möchten, kommt es zu einem Zusammenführungskonflikt: Soll der Titel „Hallo“ oder „Hey!“ lauten?

Wenn Sie versuchen, diese Zweige zusammenzuführen, zeigt Ihnen Git, wo die Konflikte auftreten. Wir können die Änderungen, die wir nicht behalten möchten, manuell entfernen, die Änderungen speichern, die geänderte Datei erneut hinzufügen und die Änderungen übernehmen.

Fertig! Obwohl Zusammenführungskonflikte oft ärgerlich sind, machen sie doch Sinn: Git sollte nicht raten müssen, welche Änderungen wir behalten wollen.

Rebasing

Wir haben gerade gesehen, dass Sie Änderungen von einem Branch auf einen anderen Branch anwenden können, indem Sie git merge ausführen. Eine andere Möglichkeit, Änderungen von einem Zweig in einen anderen zu integrieren, besteht darin, einen Git-Rebase durchzuführen.

git rebase kopiert die Commits des aktuellen Zweigs in den angegebenen Zweig.

Perfekt, jetzt haben wir alle Änderungen am Master-Zweig im Dev-Zweig.

Es gibt einen wesentlichen Unterschied zwischen Rebasing und Merging: Git versucht nicht zu bestimmen, welche Dateien behalten werden sollen und welche nicht. Der von uns neu erstellte Zweig enthält immer die neuesten Änderungen, die wir behalten möchten! Auf diese Weise geraten wir nicht in Zusammenführungskonflikte und behalten einen schönen, linearen Git-Verlauf bei.

Das obige Beispiel zeigt die Neubasierung auf dem Master-Zweig. Bei größeren Projekten ist dies jedoch in der Regel nicht erforderlich. Git Rebase ändert den Projektverlauf, wenn neue Hashes für kopierte Commits erstellt werden.

Wenn Sie einen Feature-Branch entwickeln und der Master-Branch aktualisiert wurde, ist eine Neubasierung sehr nützlich. Sie können alle Aktualisierungen für Ihren Zweig abrufen, was zukünftige Zusammenführungskonflikte verhindert.

Interaktives Rebase

Bevor wir ein Rebase für Commits durchführen, können wir diese ändern! Wir können interaktives Rebasing verwenden, um diese Aufgabe zu erfüllen. Interaktives Rebasing ist nützlich, wenn Sie sich in dem Zweig befinden, den Sie gerade entwickeln, und bestimmte Commits ändern möchten.

Auf dem Commit, das wir umbasieren, können wir die folgenden 6 Aktionen ausführen:

• Umformulieren: Ändern Sie die Commit-Informationen;

• Bearbeiten: Ändern Sie dieses Commit;

• squash: Den Commit mit dem vorherigen Commit zusammenführen;

• fixup: Den Commit mit dem vorherigen Commit zusammenführen, ohne die Protokollnachricht des Commits beizubehalten;

• exec: bei jedem Lauf der Befehl, den wir auf das Commit umstellen möchten;

• drop: Entfernen Sie das Commit.

Super! Auf diese Weise haben wir die volle Kontrolle über unsere Commits. Wenn Sie ein Commit entfernen möchten, lassen Sie es einfach fallen.

Wenn Sie mehrere Commits zusammenführen möchten, um einen klaren Commit-Verlauf zu erhalten, ist das kein Problem!

Interaktives Rebase gibt Ihnen viel Kontrolle beim Rebasing, sogar über den aktuell aktiven Zweig.

Zurücksetzen

Dieser Befehl wird verwendet, wenn wir die zuvor übermittelten Änderungen nicht möchten. Möglicherweise handelt es sich um einen WIP-Commit, oder es handelt sich um einen Commit, der einen Fehler verursacht hat. In diesem Fall müssen Sie einen Git-Reset durchführen.

Git Reset ermöglicht es uns, die Dateien auf dem aktuellen Desktop nicht mehr zu verwenden und ermöglicht uns zu steuern, wohin HEAD zeigen soll.

Soft-Reset

Ein Soft-Reset verschiebt HEAD zum angegebenen Commit (oder zum Index des Commits im Vergleich zu HEAD), ohne nach diesem Commit hinzugefügte Änderungen zu entfernen!

Angenommen, wir möchten Commit 9e78i, das eine style.css-Datei hinzufügt, nicht beibehalten, und wir möchten auch Commit 035cc, das eine index.js-Datei hinzufügt, nicht beibehalten. Wir möchten jedoch die neu hinzugefügten Dateien style.css und index.js behalten! Dies ist ein perfekter Anwendungsfall für einen Soft-Reset.

Nachdem Sie git status eingegeben haben, werden Sie sehen, dass wir immer noch Zugriff auf alle Änderungen haben, die an den vorherigen Commits vorgenommen wurden. Das ist großartig, denn wir können den Inhalt dieser Dateien korrigieren und sie später erneut einreichen!

Hard-Reset

Manchmal möchten wir die durch einen bestimmten Commit eingeführten Änderungen nicht beibehalten. Im Gegensatz zu einem Soft-Reset sollten wir nie wieder darauf zugreifen müssen. Git sollte einfach den Gesamtzustand direkt auf den Zustand vor einem bestimmten Commit zurücksetzen: Dies umfasst sogar Änderungen, die Sie im Arbeitsverzeichnis und an Staging-Dateien vorgenommen haben.

Git hat die durch 9e78i und 035cc eingeführten Änderungen verworfen und den Status auf den Status von ec5be zurückgesetzt.

Zurücksetzen

Eine andere Möglichkeit, Änderungen rückgängig zu machen, besteht darin, Git-Revert durchzuführen. Indem wir einen Wiederherstellungsvorgang für einen bestimmten Commit durchführen, erstellen wir einen neuen Commit, der die rückgängig gemachten Änderungen enthält.

Angenommen, ec5be fügt eine index.js-Datei hinzu. Doch dann stellten wir fest, dass wir die durch diesen Commit eingeführten Änderungen nicht mehr benötigten. Dann stellen Sie die ec5be-Übermittlung wieder her!

Perfekt! Commit 9e78i macht die durch Commit ec5be eingeführten Änderungen rückgängig. git revert ist nützlich, wenn ein bestimmtes Commit rückgängig gemacht werden soll, ohne den Verlauf des Zweigs zu ändern.

Rosinenpickerei

Wenn ein bestimmter Zweig einen Commit enthält, den unser aktiver Zweig benötigt, führen wir eine Rosinenauswahl für diesen Commit durch! Wenn wir einen Commit auswählen, erstellen wir einen neuen Commit im aktiven Zweig, der die durch den ausgewählten Commit eingeführten Änderungen enthält.

Angenommen, Commit 76d12 im Entwicklungszweig fügt eine Änderung zur Datei index.js hinzu und wir möchten sie in den Hauptzweig integrieren. Wir wollen nicht den gesamten Entwicklungszweig, nur diesen Commit!

Jetzt enthält der Hauptzweig die durch 76d12 eingeführten Änderungen.

Fetching

Wenn Sie einen Remote-Git-Zweig haben, beispielsweise einen Zweig auf GitHub, können Sie den Abruf verwenden, wenn der Remote-Zweig Commits enthält, die der aktuelle Zweig nicht hat. Zum Beispiel, wenn eine andere Niederlassung zusammengelegt wird oder Ihr Kollege eine schnelle Lösung vorschlägt.

Durch die Ausführung von git fetch in diesem Remote-Zweig können wir diese Änderungen lokal abrufen. Dies hat keinerlei Auswirkungen auf Ihre lokale Zweigstelle: fetch lädt lediglich die neuen Daten herunter.

Jetzt können wir alle Änderungen seit dem letzten Push sehen. Die neuen Daten sind nun lokal und wir können entscheiden, was wir damit machen möchten.

Pulling

Obwohl Git Fetch verwendet werden kann, um die Remote-Informationen einer Filiale abzurufen, können wir auch Git Pull durchführen. Bei Git Pull handelt es sich eigentlich um zwei Befehle, die in einem zusammengefasst sind: Git Fetch und Git Merge. Wenn wir Änderungen aus der Quelle abrufen, rufen wir zuerst alle Daten wie Git Fetch ab und dann werden die neuesten Änderungen automatisch in den lokalen Zweig eingefügt.

Großartig, wir sind jetzt perfekt mit der Remote-Filiale synchronisiert und haben auch alle aktuellen Änderungen!

Reflog

Jeder macht Fehler, aber es ist in Ordnung, Fehler zu machen! Manchmal haben Sie möglicherweise das Gefühl, dass Sie Ihr Git-Repository vollständig beschädigt haben, sodass Sie es am liebsten vollständig löschen würden.

git reflog ist ein sehr nützlicher Befehl, der das Protokoll aller durchgeführten Aktionen anzeigen kann. Dazu gehören Zusammenführungen, Zurücksetzungen, Wiederherstellungen und im Grunde alle Änderungen, die Sie an Ihrem Zweig vornehmen.

Wenn Sie einen Fehler machen, können Sie ihn leicht wiederholen, indem Sie HEAD basierend auf den vom Reflog bereitgestellten Informationen zurücksetzen!

Angenommen, wir müssen den ursprünglichen Zweig nicht wirklich zusammenführen. Wenn wir den Befehl „git reflog“ ausführen, können wir sehen, dass der Status dieses Repos vor der Zusammenführung bei HEAD@{1} war. Dann führen wir einen Git-Reset durch und leiten HEAD an den Speicherort von HEAD@{1} um.

Wir können sehen, dass die neueste Aktion in den Reflog verschoben wurde.

Das obige ist der detaillierte Inhalt vonDutzende animierte Bilder zeigen Ihnen, wie Git funktioniert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!