Wie (und warum!) Sie Ihren Git-Commit-Verlauf sauber halten

Commits sind einer der Schlüsselbestandteile eines Git-Repositorys. Darüber hinaus ist die Festschreibungsnachricht ein Lebensprotokoll für das Repository. Während sich das Projekt / Repository im Laufe der Zeit weiterentwickelt (neue Funktionen werden hinzugefügt, Fehler werden behoben, die Architektur wird überarbeitet), sind Commit-Nachrichten der Ort, an dem man sehen kann, was und wie geändert wurde. Daher ist es wichtig, dass diese Nachrichten die zugrunde liegende Änderung kurz und präzise widerspiegeln.

Warum ist ein aussagekräftiger Git-Commit-Verlauf wichtig?

Was macht Git-Commit? Git-Commit-Nachrichten sind die Fingerabdrücke, die Sie auf dem Code hinterlassen, den Sie berühren. Jeder Code, den Sie heute festschreiben, in einem Jahr, wenn Sie sich dieselbe Änderung ansehen, wäre dankbar für eine klare, aussagekräftige Festschreibungsnachricht, die Sie geschrieben haben, und das wird auch so sein Erleichtern Sie das Leben Ihrer Entwicklerkollegen. Wenn Commits aufgrund des Kontexts isoliert werden, ist ein Fehler, der durch ein bestimmtes Commit verursacht wurde, schneller zu finden und desto einfacher ist es, das Commit zurückzusetzen, das den Fehler verursacht hat.

Bei der Arbeit an einem großen Projekt werden häufig viele bewegliche Teile bearbeitet, die aktualisiert, hinzugefügt oder entfernt werden. Es kann schwierig sein, sicherzustellen, dass Commit-Nachrichten in solchen Fällen beibehalten werden, insbesondere wenn sich die Entwicklung über Tage erstreckt. Wochen oder sogar Monate, um den Aufwand für die Aufrechterhaltung der Concis zu vereinfachen In diesem Artikel werden einige der häufigsten Situationen verwendet, mit denen ein Entwickler bei der Arbeit an einem Git-Repository konfrontiert sein kann.

• Situation 1: Ich muss das letzte Commit ändern
• Situation 2: Ich muss ein bestimmtes Commit ändern.
• Situation 3: Ich muss Commits hinzufügen, entfernen oder kombinieren.
• Situation 4: Mein Commit-Verlauf wird nicht ausgeführt Sinn, ich brauche einen Neuanfang!

Aber bevor wir eintauchen, lassen Sie uns kurz durchgehen, wie ein typischer Entwicklungsworkflow in unserer hypothetischen Ruby-Anwendung aussieht.

Hinweis: In diesem Artikel wird davon ausgegangen, dass Sie sich mit den Grundlagen von Git, der Funktionsweise von Zweigen, dem Hinzufügen nicht festgeschriebener Änderungen eines Zweigs zur Bühne und dem Festschreiben der Änderungen auskennen. Wenn Sie sich über diese Abläufe nicht sicher sind, ist unsere Dokumentation ein guter Ausgangspunkt.

Ein Tag im Leben

Hier arbeiten wir an einem kleinen Ruby on Rails-Projekt, in dem wir arbeiten Sie müssen eine Navigationsansicht auf der Startseite hinzufügen. Dazu müssen Sie mehrere Dateien aktualisieren und hinzufügen. Im Folgenden finden Sie eine schrittweise Aufschlüsselung des gesamten Ablaufs:

• Sie beginnen mit der Aktualisierung einer Datei an einer Funktion ; nennen wir es application_controller.rb
• Für diese Funktion müssen Sie auch eine Ansicht aktualisieren: index.html.haml
• Sie haben einen Teil hinzugefügt, der auf der Indexseite verwendet wird: _navigation.html.haml
• Die Stile für die Seite müssen ebenfalls aktualisiert werden, um den von uns hinzugefügten Teil wiederzugeben: styles.css.scss
• Die Funktion ist jetzt mit den gewünschten Änderungen bereit. Es ist auch Zeit, Tests zu aktualisieren. Folgende Dateien müssen aktualisiert werden:
  • application_controller_spec.rb
  • navigation_spec.rb
• Die Tests werden wie erwartet aktualisiert und bestanden. Jetzt ist es an der Zeit, die Änderungen festzuschreiben!

Da alle Dateien zu verschiedenen Gebieten der Architektur gehören, legen wir fest Die Änderungen sind voneinander isoliert, um sicherzustellen, dass jedes Commit einen bestimmten Kontext darstellt und in einer bestimmten Reihenfolge ausgeführt wird. Normalerweise bevorzuge ich das Backend – > Frontend-Reihenfolge, in der die meisten backend-zentrierten Änderungen zuerst festgeschrieben werden, gefolgt von der mittleren Ebene und dann von frontend-zentrierten Änderungen in den Git-Listen-Commits. P. >

Nachdem wir unsere Änderungen festgeschrieben haben, erstellen wir eine Zusammenführungsanforderung mit dem Zweig. Sobald Sie eine Zusammenführungsanforderung geöffnet haben, wird diese normalerweise von Ihrem Peer überprüft, bevor die Änderungen in den master -Zweig von repo zusammengeführt werden. Lassen Sie uns nun lernen, mit welchen unterschiedlichen Situationen wir möglicherweise enden während der Codeüberprüfung.

Situation 1: Ich muss das letzte Commit ändern.

Stellen Sie sich einen Fall vor, in dem der Prüfer styles.css.scss und schlug eine Änderung vor. In einem solchen Fall ist es sehr einfach, die Änderung vorzunehmen, da die Änderungen am Stylesheet Teil des letzten Commits in Ihrem Zweig sind. So können wir damit umgehen:

• Sie nehmen direkt die erforderlichen Änderungen an styles.css.scss in Ihrer Zweigstelle vor.
• Einmal Wenn Sie mit den Änderungen fertig sind, fügen Sie diese Änderungen der Bühne hinzu. Führen Sie git add styles.css.scss aus.
• Sobald Änderungen vorgenommen wurden, müssen wir diese Änderungen zu unserem letzten Commit hinzufügen. Führen Sie git commit --amend aus.
  • Befehlsaufschlüsselung: Hier bitten wir den Befehl git commit, die darin enthaltenen Änderungen zu ändern Stufe zum letzten Commit.
• Dies öffnet Ihr letztes Commit in Ihrem Git-definierten Texteditor, der die Commit-Meldung Stile für die Navigation hinzufügen enthält.
• Da wir nur die CSS-Deklaration aktualisiert haben, müssen wir die Commit-Nachricht nicht ändern.Zu diesem Zeitpunkt können Sie einfach den von Git für Sie geöffneten Texteditor speichern und beenden. Ihre Änderungen werden im Commit wiedergegeben.

Da Sie ein vorhandenes Commit geändert haben, sind diese Änderungen erforderlich um mit git push --force-with-lease <remote_name> <branch_name> zwangsweise auf Ihr Remote-Repo gedrückt zu werden. Dieser Befehl überschreibt das Commit Add styles for navigation auf dem Remote-Repo mit einem aktualisierten Commit, das wir gerade in unserem lokalen Repo vorgenommen haben.

Beachten Sie Folgendes, wenn Sie das Drücken von Zweigen erzwingen Wenn Sie mit mehreren Personen an demselben Zweig arbeiten, kann das erzwungene Drücken anderen Benutzern Probleme bereiten, wenn sie versuchen, ihre Änderungen normalerweise auf einen Remote-Zweig zu übertragen, für den neue Commits erzwungen werden. Verwenden Sie diese Funktion daher mit Bedacht. Weitere Informationen zu Git Force Push-Optionen finden Sie hier.

Situation 2: Ich muss ein bestimmtes Commit ändern.

In der vorherigen Situation war das Update ziemlich einfach, da wir es ändern mussten Nur unser letztes Git-Commit, aber stellen Sie sich vor, der Prüfer schlägt vor, etwas in _navigation.html.haml zu ändern. In diesem Fall handelt es sich um ein zweites Commit von oben, sodass das Ändern nicht so direkt ist wie in der ersten Situation. Lassen Sie uns sehen, wie wir damit umgehen können:

Wann immer ein Commit durchgeführt wird In einem Zweig erstellt, wird es durch eine eindeutige SHA1-Hash-Zeichenfolge identifiziert. Stellen Sie sich das als eine eindeutige ID vor, die ein Commit von einem anderen trennt. Sie können alle Commits zusammen mit ihren SHA1-Hashes in einem Zweig anzeigen, indem Sie git log ausführen. Damit sehen Sie eine Ausgabe, die wie folgt aussieht, wobei die neuesten Commits oben stehen:

Hier kommt der Befehl git rebase ins Spiel. Wann immer wir ein bestimmtes Commit mit git rebase bearbeiten möchten, müssen wir zuerst unseren Zweig neu gründen, indem wir HEAD auf den Punkt unmittelbar vor dem Commit zurücksetzen, den wir bearbeiten möchten. In unserem Fall müssen wir das Commit ändern, das Page Navigation View lautet.

Beachten Sie hier den Commit-Hash, der unmittelbar vor dem Commit liegt, den wir ändern möchten. Kopieren Sie den Hash und führen Sie die folgenden Schritte aus:

• Starten Sie den Zweig neu, um ihn vor unserem Ziel-Commit zu verschieben. Führen Sie git rebase -i 8d74af102941aa0b51e1a35b8ad731284e4b5a20
  • Befehlsaufschlüsselung aus: Hier führen wir den rebase Befehl von Git mit interaktivem Modus und bereitgestelltem SHA1-Hash aus as commit to rebase to.
• Hiermit wird der Rebase-Befehl für Git im interaktiven Modus ausgeführt und der Texteditor geöffnet, in dem alle Commits angezeigt werden, die nach dem Commit ausgeführt wurden, auf den Sie neu basiert haben . Es sieht ungefähr so aus:

Beachten Sie, dass jedes Commit ein Wort davor und im Inhalt unten gibt es alle möglichen Schlüsselwörter, die wir verwenden können. Da wir ein Commit bearbeiten möchten, müssen wir pick 4155df1cdc7 Page Navigation View in edit 4155df1cdc7 Page Navigation View ändern. Speichern Sie die Änderungen und beenden Sie den Editor.

Jetzt wird Ihr Zweig auf den Zeitpunkt unmittelbar vor dem von Ihnen vorgenommenen Commit zurückgesetzt, einschließlich _navigation.html.haml. Öffnen Sie die Datei und führen Sie die gewünschten Änderungen gemäß dem Überprüfungsfeedback durch. Sobald Sie mit den Änderungen fertig sind, führen Sie sie durch Ausführen von git add _navigation.html.haml aus.

Da wir die Änderungen vorgenommen haben, ist es Zeit, den Zweig HEAD zurück zum zu verschieben Commit, das wir ursprünglich hatten (einschließlich der neuen Änderungen, die wir hinzugefügt haben), führen Sie git rebase --continue aus. Dadurch wird Ihr Standardeditor im Terminal geöffnet und die Commit-Nachricht angezeigt, die wir während des Rebases bearbeitet haben. Page Navigation View. Sie können diese Nachricht ändern, wenn Sie möchten, aber wir würden sie so lassen, wie sie ist. Speichern Sie den Editor und beenden Sie ihn. An diesem Punkt spielt Git alle Commits erneut ab Das nach dem Commit, das Sie gerade bearbeitet haben, und der Zweig HEAD ist wieder das oberste Commit, das wir ursprünglich hatten, und enthält auch die neuen Änderungen, die Sie an einem der Commits vorgenommen haben.

Da wir ein Commit erneut geändert haben, das bereits im Remote-Repo vorhanden ist, müssen wir diesen Zweig mit git push --force-with-lease <remote_name> <branch_name> erneut erzwingen.

Situation 3 : Ich muss Commits hinzufügen, entfernen oder kombinieren

Eine häufige Situation ist, wenn Sie mehrere Commits durchgeführt haben, um etwas zuvor festgeschriebenes zu beheben. Reduzieren wir sie jetzt so weit wie möglich und kombinieren sie mit den ursprünglichen Commits.

Sie müssen lediglich die interaktive Rebase wie in den anderen Szenarien starten.

Stellen Sie sich nun vor, Sie möchten all diese Korrekturen in c22a3fa0c5c Render navigation partial kombinieren. Sie müssen nur:

1. Verschieben Sie die Fixes nach oben, sodass sie direkt unter dem Commit liegen, das Sie am Ende beibehalten möchten.
2. Ändern Sie pick in squash oder fixup für jeden der Fixes.

Hinweis: squash behält die Festschreibungsnachrichten in der Beschreibung bei. fixup vergisst die Festschreibungsnachrichten der Fixes und behält das Original bei.

Am Ende haben Sie Folgendes:

Speichern Sie die Änderungen und beenden Sie den Editor , und du bist fertig! Dies ist der resultierende Verlauf:

Nach wie vor müssen Sie jetzt nur noch git push --force-with-lease <remote_name> <branch_name> und die Änderungen sind aktiv.

Wenn Sie das Commit vollständig aus dem Zweig entfernen möchten, anstatt squash oder fixup, schreiben Sie einfach drop oder löschen Sie einfach diese Zeile.

Vermeiden Sie Konflikte

Um Konflikte zu vermeiden, stellen Sie sicher, dass Sie festgeschrieben werden Wenn Sie die Timeline nach oben verschieben, werden nicht dieselben Dateien berührt, die von den nach ihnen verbleibenden Commits berührt wurden.

Pro-Tipp : Schnelle Korrekturen

Wenn Sie genau wissen, welches Commit Sie reparieren möchten, müssen Sie beim Festschreiben keine Gehirnzyklen verschwenden, wenn Sie an gute temporäre Namen für „Fix 1“, „Fix 2“, …, denken. „Fix 42“.

Schritt 1: Treffen Sie --fixup

Nachdem Sie die Änderungen vorgenommen haben, korrigieren Sie alles, was repariert werden muss. Nur Git schreibt alle Änderungen wie folgt fest:

(Beachten Sie, dass dies der Hash für das Commit ist c22a3fa0c5c Render navigation partial)

Dadurch wird diese Commit-Nachricht generiert: fixup! Render navigation partial.

Schritt 2: Und der Sidekick --autosquash

Einfache interaktive Rebase. Sie können festlegen, dass git die fixup s automatisch an der richtigen Stelle platziert.

git rebase -i 4155df1cdc7 --autosquash

Der Verlauf wird folgendermaßen angezeigt:

Bereit für Sie Überprüfen Sie und fahren Sie fort.

Wenn Sie sich abenteuerlustig fühlen, können Sie eine nicht interaktive Rebase durchführen git rebase --autosquash, aber nur, wenn Sie gerne gefährlich leben, wie Sie es möchten Ich habe keine Gelegenheit, die Kürbisse zu überprüfen, bevor sie erneut angewendet werden.

Situation 4: Mein Git-Commit-Verlauf macht keinen Sinn, ich brauche einen Neuanfang!

Wenn wir „Wenn Sie an einer großen Funktion arbeiten, werden häufig mehrere Änderungen an Korrekturen und Überprüfungen vorgenommen, die häufig festgeschrieben werden. Anstatt den Zweig ständig neu zu gründen, können wir die Bereinigung von Festschreibungen bis zum Ende der Entwicklung belassen.

Hier ist das Erstellen von Patch-Dateien äußerst praktisch. Tatsächlich waren Patch-Dateien die primäre Methode, um Code während der Zusammenarbeit über E-Mail zu teilen bei großen Open-Source-Projekten, bevor Git-basierte Dienste wie GitLab Entwicklern zur Verfügung standen. Stellen Sie sich vor, Sie haben einen solchen Zweig (z. B. add-page-navigation), in dem es Unmengen von Commits gibt, die die zugrunde liegenden Änderungen nicht klar vermitteln. So können Sie eine Patch-Datei für alle erstellen Die Änderungen, die Sie in diesem Zweig vorgenommen haben:

• Der erste Schritt zum Erstellen der Patch-Datei besteht darin, sicherzustellen, dass in Ihrem Zweig alle Änderungen von master verzweigen und hat keine Konflikte damit.
• Sie können git rebase master oder git merge master ausführen, während Sie überprüft werden Klicken Sie im Zweig add-page-navigation auf, um alle Änderungen von master an Ihrem Zweig abzurufen.
• Erstellen Sie nun die Patch-Datei ; run git diff master add-page-navigation > ~/add_page_navigation.patch.
  • Befehlsaufschlüsselung: Hier verwenden wir die Diff-Funktion von Git und fragen nach einem Diff zwischen master branch und add-page-navigation verzweigen und die Ausgabe (über das Symbol >) in eine Datei mit dem Namen in unseren us er Home-Verzeichnis (normalerweise ~/ in * nix-Betriebssystemen).
• Sie können einen beliebigen Pfad angeben, in dem diese Datei gespeichert werden soll in und der Dateiname und die Dateierweiterung können beliebig sein.
• Sobald der Befehl ausgeführt wird und Sie keine Fehler sehen, wird die Patch-Datei generiert.
• Jetzt auschecken master Zweig; Führen Sie git checkout master aus.
• Löschen Sie den Zweig add-page-navigation aus dem lokalen Repo. Führen Sie git branch -D add-page-navigation aus. Denken Sie daran, dass wir bereits Änderungen an diesem Zweig in einer erstellten Patch-Datei haben.
• Erstellen Sie jetzt einen neuen Zweig mit demselben Namen (während master ausgecheckt ist). Führen Sie git checkout -b add-page-navigation aus.
• Zu diesem Zeitpunkt ist dies ein neuer Zweig und hat keine Ihrer Änderungen.
• Übernehmen Sie abschließend Ihre Änderungen aus der Patch-Datei; git apply ~/add_page_navigation.patch.
• Hier werden alle Ihre Änderungen in einem Zweig angewendet und erscheinen als nicht festgeschrieben, als ob alle Ihre Änderungen wo getan, aber keine der Änderungen wurde tatsächlich in der Verzweigung festgeschrieben.
• Jetzt können Sie einzelne Dateien oder Dateien, die nach Wirkungsbereichen gruppiert sind, in der gewünschten Reihenfolge mit präzisen Festschreibungsnachrichten festschreiben.

Wie in früheren Situationen haben wir im Grunde den gesamten Zweig modifiziert, also ist es Zeit, Push zu erzwingen!

Fazit

Während wir die häufigsten und grundlegendsten Situationen behandelt haben, die in einem täglichen Workflow mit Git auftreten, ist das Umschreiben des Git-Verlaufs ein großes Thema, mit dem Sie sich vertraut machen In den obigen Tipps erfahren Sie in der offiziellen Git-Dokumentation weiterführende Konzepte zum Thema. Happy git „ing!

Foto von pan xiaozhen auf Unsplash