Wie werde ich Git-Experte?

Ich habe beim Festschreiben einen Fehler gemacht. Wie behebe ich den Fehler?

Meine Commit-Historie ist ein Durcheinander. Wie mache ich es ordentlicher?

Wenn Sie jemals die oben genannten Fragen hatten, dann ist dieser Beitrag für Sie. Dieser Beitrag behandelt eine Liste von Themen, die Sie zu einem Git-Experten machen.

Wenn Sie keine Git-Grundlagen kennen, klicken Sie hier, um meinen Blog über Git-Grundlagen zu lesen. Sie müssen die Grundlagen von Git kennen, um diesen Artikel optimal nutzen zu können.

Ich habe bei meinem Commit einen Fehler gemacht. Was soll ich machen?

Szenario 1

Angenommen, Sie haben eine Reihe von Dateien festgeschrieben und festgestellt, dass die von Ihnen eingegebene Festschreibungsmeldung tatsächlich nicht klar ist. Jetzt möchten Sie die Festschreibungsmeldung ändern. Dazu können Sie git commit --amend verwenden

git commit --amend -m "Neue Commit-Nachricht"

Szenario 2

Nehmen wir an, Sie wollten sechs Dateien festschreiben, haben jedoch versehentlich nur fünf Dateien festgeschrieben. Sie können sich vorstellen, dass Sie ein neues Commit erstellen und die sechste Datei zu diesem Commit hinzufügen können.

An diesem Ansatz ist nichts auszusetzen. Wäre es nicht besser, wenn Sie diese Datei tatsächlich zu Ihrem vorherigen Commit selbst hinzufügen könnten, um einen ordentlichen Commit-Verlauf beizubehalten? Dies kann auch über git commit --amend erfolgen:

git add file6
git commit --amend --no-edit

--no-edit bedeutet, dass sich die Commit-Nachricht nicht ändert.

Szenario 3

Wann immer Sie ein Commit in Git durchführen, sind an das Commit ein Autorenname und eine Autoren-E-Mail gebunden. Im Allgemeinen richten Sie beim erstmaligen Einrichten von Git den Namen des Autors und die E-Mail-Adresse ein. Sie müssen sich nicht bei jedem Commit um die Details des Autors kümmern.

Es ist jedoch möglich, dass Sie für ein bestimmtes Projekt eine andere E-Mail-ID verwenden möchten. Sie müssen die E-Mail-ID für dieses Projekt mit dem folgenden Befehl konfigurieren:

git config user.email "Ihre E-Mail-ID"

Nehmen wir an, Sie haben vergessen, die E-Mail zu konfigurieren, und haben bereits Ihr erstes Commit ausgeführt. Mit Amend können Sie auch den Autor Ihres vorherigen Commits ändern. Der Autor des Commits kann mit dem folgenden Befehl geändert werden:

git commit --amend --author "Autorenname "

Punkt zu beachten

Verwenden Sie den Befehl "amend" nur in Ihrem lokalen Repository. Die Verwendung von amend für das Remote-Repository kann viel Verwirrung stiften.

Meine Commit-Geschichte ist ein Durcheinander. Wie gehe ich damit um?

Angenommen, Sie arbeiten an einem Code. Sie wissen, dass der Code ungefähr zehn Tage in Anspruch nehmen wird. Innerhalb dieser zehn Tage werden die anderen Entwickler ebenfalls Code für das Remote-Repository festschreiben.

Es wird empfohlen, Ihren lokalen Repository-Code mit dem Code im Remote-Repository auf dem neuesten Stand zu halten. Dies vermeidet viele Zusammenführungskonflikte später, wenn Sie eine Pull-Anforderung auslösen. Sie entscheiden also, dass Sie die Änderungen alle zwei Tage aus dem Remote-Repository abrufen.

Jedes Mal, wenn Sie den Code aus dem Remote-Repository in das lokale Repository ziehen, wird in Ihrem lokalen Repository ein neues Merge-Commit erstellt. Dies bedeutet, dass Ihr lokaler Commit-Verlauf viele Merge-Commits enthalten wird, die für den Prüfer verwirrend wirken können.

So würde der Festschreibungsverlauf in Ihrem lokalen Repository aussehen.

Wie lassen Sie die Commit-Historie übersichtlicher aussehen?

Dies ist, wo Rebase zur Rettung kommt.

Was ist ein Rebasing?

Lassen Sie mich dies anhand eines Beispiels erläutern.

Dieses Diagramm zeigt die Commits im Release-Zweig und in Ihrem Feature-Zweig
  1. Der Zweig Release hat drei Festschreibungen: Rcommit1, Rcommit2 und Rcommit3.
  2. Sie haben Ihren Feature-Zweig aus dem Release-Zweig erstellt, als er nur ein Commit hatte, nämlich Rcommit1.
  3. Sie haben dem Zweig "Feature" zwei Commits hinzugefügt. Sie sind Fcommit1 und Fcommit2.
  4. Ihr Ziel ist es, die Commits aus dem Release-Zweig in Ihren Feature-Zweig zu bekommen.
  5. Sie werden dazu Rebase verwenden.
  6. Der Name des Release-Zweigs sei release und der Name des Feature-Zweigs sei feature.
  7. Der Neustart kann mit den folgenden Befehlen durchgeführt werden:
Git Checkout-Funktion
Git Rebase Release

Wiederablassen

Ihr Ziel ist es, sicherzustellen, dass der Feature-Zweig den neuesten Code aus dem Release-Zweig erhält.

Beim erneuten Starten wird versucht, jedes Commit einzeln hinzuzufügen und auf Konflikte zu prüfen. Klingt das verwirrend?

Lassen Sie mich anhand eines Diagramms erklären.

Dies zeigt, was das Umbasieren tatsächlich intern bewirkt:

Schritt 1

  1. In dem Moment, in dem Sie den Befehl ausführen, wird der Feature-Zweig auf den Kopf des Release-Zweigs gezeigt.
  2. Der Zweig "Feature" verfügt jetzt über drei Festschreibungen: "Rcommit1", "Rcommit2" und "Rcommit3".
  3. Sie fragen sich vielleicht, was mit Fcommit1 und Fcommit2 passiert ist.
  4. Die Commits sind noch vorhanden und werden in den folgenden Schritten verwendet.

Schritt 2

  1. Jetzt versucht Git, Fcommit1 zum Feature-Zweig hinzuzufügen.
  2. Wenn kein Konflikt besteht, wird Fcommit1 nach Rcommit3 hinzugefügt
  3. Wenn es einen Konflikt gibt, benachrichtigt Git Sie und Sie müssen den Konflikt manuell lösen. Nachdem der Konflikt behoben ist, verwenden Sie die folgenden Befehle, um mit dem erneuten Basieren fortzufahren
git füge fixedfile hinzu
Git Rebase - weiter

Schritt 3

  1. Sobald Fcommit1 hinzugefügt wurde, wird Git versuchen, Fcommit2 hinzuzufügen.
  2. Wenn es keinen Konflikt gibt, wird Fcommit2 nach Fcommit1 hinzugefügt, und die Wiederherstellung ist erfolgreich.
  3. Wenn es einen Konflikt gibt, benachrichtigt Git Sie und Sie müssen ihn manuell lösen. Verwenden Sie nach dem Lösen von Konflikten die in Schritt 2 genannten Befehle
  4. Nachdem der gesamte Rebase abgeschlossen ist, werden Sie feststellen, dass der Feature-Zweig über Rcommit1, Rcommit2, Rcommit3, Fcommit1 und Fcommit2 verfügt.

Punkte zu beachten

  1. Sowohl Rebase als auch Merge sind in Git nützlich. Einer ist nicht besser als der andere.
  2. Im Falle einer Zusammenführung wird ein Zusammenführungs-Commit durchgeführt. Im Falle eines Rebases gibt es kein zusätzliches Commit wie ein Merge-Commit.
  3. Eine bewährte Methode besteht darin, die Befehle an verschiedenen Stellen zu verwenden. Verwenden Sie rebase, wenn Sie Ihr lokales Code-Repository mit dem neuesten Code aus dem Remote-Repository aktualisieren. Verwenden Sie "Zusammenführen", wenn Sie Pull-Anforderungen bearbeiten, um den Feature-Zweig wieder mit dem Release- oder Master-Zweig zusammenzuführen.
  4. Durch die Verwendung von Rebase wird der Festschreibungsverlauf geändert (dadurch wird er übersichtlicher). Das Ändern des Commit-Verlaufs birgt jedoch Risiken. Stellen Sie also sicher, dass Sie niemals rebase für einen Code verwenden, der sich im Remote-Repository befindet. Verwenden Sie rebase immer nur, um den Commit-Verlauf Ihres lokalen Repo-Codes zu ändern.
  5. Wenn ein Remoterepository wiederhergestellt wird, kann dies große Verwirrung stiften, da andere Entwickler den neuen Verlauf nicht erkennen.
  6. Auch wenn die Wiederherstellung im Remote-Repository durchgeführt wird, kann dies zu Problemen führen, wenn andere Entwickler versuchen, den neuesten Code aus dem Remote-Repository abzurufen. Also wiederhole ich nochmal, benutze immer rebase nur für das lokale Repository

Glückwunsch

Sie sind jetzt Git-Experte expert

In diesem Beitrag haben Sie Folgendes erfahren:

  • Änderungszusagen
  • zurückweisen

Beides sind sehr nützliche Konzepte. Erforschen Sie die Welt von Git und erfahren Sie noch mehr.

Über den Autor

Ich liebe Technologie und verfolge die Fortschritte auf diesem Gebiet. Ich helfe auch gerne anderen mit meinen technologischen Kenntnissen.

Sie können sich gerne über mein LinkedIn-Konto mit mir in Verbindung setzen https://www.linkedin.com/in/aditya1811/

Sie können mir auch auf Twitter https://twitter.com/adityasridhar18 folgen

Meine Website: https://adityasridhar.com/

Andere Beiträge von mir

Best Practices bei der Verwendung von Git

Eine Einführung in Git

So nutzen Sie Git effizient