Erweiterte Git-Workflows und -Nutzung

Kürzlich haben wir uns mit den Grundlagen für den Einstieg in die Verwendung von Git für die Quellcodeverwaltung in Ihren Projekten befasst. Obwohl dies ein guter Ausgangspunkt ist, gibt es eine Reihe anderer Befehle und Git-Workflows, die Ihnen helfen werden, sich mit der Verwendung von Git in Ihrer täglichen Codierungsarbeit vertraut zu machen.

Git-Workflows

Als ich anfing, Git zu verwenden, dachte ich, ich wüsste, wie man es richtig benutzt. Mein idealer Ansatz war, alle Änderungen an einer Stelle ohne Branches vorzunehmen und sie dann in das Repository zu schreiben und weiterzuarbeiten.

Obwohl es besser war, die Versionskontrolle nicht zu verwenden, dauerte es eine Weile, bis mir klar wurde, dass ich den größten Teil der von Git bereitgestellten Leistung nicht nutzte. Damit Git für mich funktioniert, brauchte ich eine Strategie, um meine Änderungen zu verzweigen und zusammenzuführen.

Dann kam Git-Flow heraus und ich übernahm es als meine Strategie. Ich erinnere mich noch, dass ich das Gefühl hatte, hinter einen Vorhang zu spähen, wo die großartigen Entwickler waren. Ich hatte jetzt Einblick in ihre Arbeitsweise und konnte beginnen, einer von ihnen zu werden.

Aber Git-Flow passt nicht zu jedem Szenario, also schauen wir uns, während wir es uns ansehen, auch ein paar andere Methoden an, um Ihre Git-Projekte zu organisieren, einschließlich, wie ich meine Projekte als Einzelentwickler verwalte.

Git-Flow

Wenn ich mir jetzt Git-Flow ansehe, erkenne ich an, dass sich die Softwarelandschaft in 10 Jahren stark verändert hat und Git-Flow möglicherweise nicht die beste Option für Ihr Team ist. Als git-flow geschrieben wurde, war es selten, dass eine Anwendung viele Male an einem Tag bereitgestellt wurde. Stattdessen haben Sie wahrscheinlich alle paar Monate oder Wochen eine Hauptversionsnummer erstellt und veröffentlicht, wenn Sie in einem besonders agilen Team waren.

Schauen wir uns an, was Git-Flow ist.

Wenn Sie die vollständige ausführliche Erklärung mit Diagrammen und Git-Befehlen für Git Flow sehen möchten, sollten Sie diesen Beitrag lesen.

In Git-Flow haben zwei Branches eine unendliche Lebensdauer. Erstens main, der Code widerspiegeln sollte, der bereit ist, in Ihrer Live-/Produktionsumgebung bereitgestellt zu werden.

Zweitens haben wir unseren Entwicklungszweig. Dieser Zweig sollte die neuesten Änderungen enthalten, die für die nächste Version unserer Software bereit sind. Wenn die Änderungen in der Entwicklung für die Bereitstellung in unserer Live-Anwendung bereit sind, führen wir sie in den Hauptzweig ein und markieren sie mit der Versionsnummer, die der Release-Nummer entspricht.

Außerhalb der beiden Hauptzweige gibt es drei Arten von unterstützenden Zweigen.

1. Funktion

Ein Feature-Branch darf nur aus dem development-Branch erstellt werden. Es muss wieder in den Entwicklungszweig gemergt werden. Die Benennung kann alles sein, was die Funktion beschreibt, an der Sie arbeiten.

Wenn die Arbeit für die nächste Veröffentlichung bereit ist, wird sie wieder in den Entwicklungszweig gemergt, wo sie auf die Veröffentlichungszeit wartet.

2. Loslassen

Release-Zweige werden aus dem development-Zweig erstellt und müssen sowohl in den development- als auch in den main-Zweig zurückgeführt werden. Sie benennen einen Release-Zweig mit der Konvention release-x. In der Praxis bedeutet das normalerweise, dass Sie einen Zweig mit der Versionsnummer benennen, die Sie verwenden möchten, wie folgt: release-2.2

Sie verwenden einen Release-Branch, um die letzten Vorbereitungen für die Veröffentlichung Ihrer Software zu treffen. Dies kann das Erhöhen der Versionsnummer von Dateien, das Sicherstellen, dass Ihre Übersetzungen fertig sind, oder abschließende Codeprüfungen umfassen.

3. Hotfix

Der Hotfix-Zweig wird aus dem Hauptzweig erstellt und wird verwendet, um Änderungen zu enthalten, die sofort in der Live-Anwendung behandelt werden müssen. Dies kann ein Fehler sein, der behoben werden muss, oder ein Sicherheitsproblem, das behandelt werden muss.

Sobald das Problem behoben und in Ihrem Hauptzweig bereitgestellt wurde, markieren Sie Ihren Code mit der richtigen Versionsnummer.

Der Hauptgrund, warum Teams Git-Flow jetzt nicht verwenden, ist, dass sich die Art und Weise, wie wir Software veröffentlichen, geändert hat. Anstatt seltener größere Versionen zu veröffentlichen, können Sie eine Änderung an einer Anwendung einige Male am Tag veröffentlichen. Ich weiß, dass ich mehrmals pro Woche Arbeit an die Sites meiner Kunden schicke, sobald sie fertig sind. Wir machen keine Versionsnummern der Seite, wir verbessern sie einfach ständig.

Standard-Git-Flow ist nicht dazu gedacht, dies zu berücksichtigen.

Github-Flow

Die zweite Option, die viele Leute verwenden, ist Github Flow.

Die einzige große Regel von Github Flow ist, dass jeder Code, der sich auf dem Hauptzweig befindet, jederzeit bereitgestellt werden kann, da er produktionsbereit ist.

Alle Zweige werden aus dem Hauptzweig mit einem beschreibenden Namen für das, was Sie tun, erstellt.

Sobald Sie Ihre Änderungen fertig haben, erstellen Sie einen Pull-Request.

Pull-Requests teilen anderen mit, die am selben Code arbeiten, dass Ihre Arbeit überprüft werden kann, bevor diese Änderungen in den Hauptcode zusammengeführt werden.

Sobald Sie eine Pull-Anforderung gesendet haben, kann das Team, mit dem Sie zusammenarbeiten, die Änderungen überprüfen und Feedback geben. Wenn die Pull-Anforderung zum Zusammenführen bereit ist, wird sie mit dem Hauptzweig für Ihr Projekt zusammengeführt.

Ein Nachteil des Github-Flows für einen einzelnen Entwickler oder ein sehr kleines Team besteht darin, dass die Verwaltung einer Pull-Anforderung zusätzlichen Overhead bei der Verwaltung des Projekts verursachen kann. Deshalb verwende ich sie nicht in meiner Arbeit.

Wie ich Git-Workflows mit Kundenprojekten verwende

In meiner Kundenarbeit bin ich normalerweise der Einzige, der täglich Code für ein Projekt schreibt. Mein Kunde aktualisiert möglicherweise WordPress-Plugins oder ändert einige CSS, aber er führt keine größeren Codierungsarbeiten durch. Das heißt, wenn ich mich für Github Flow entscheiden würde, würde ich meine Pull-Requests überprüfen, was nur zusätzliche Verwaltungsprobleme verursacht. Schauen wir uns das von mir verwendete System an, das eine gewisse Ähnlichkeit mit Git-Flow und Github-Flow aufweist.

Ich habe zwei Hauptzweige namens main und staging. Die Hauptzweigspuren mit dem Code, der gerade auf der Produktionsseite läuft. Der Staging-Zweig verfolgt alles, was auf der Staging-Site getestet wird, die wir verwenden, um Änderungen zu testen, bevor wir sie auf die Live-Site übertragen.

Jeder Zweig wird aus dem Hauptzweig erstellt. Neue Features erhalten einen Namen wie diesen: feature/32-new-feature. Die Nummer 32 entspricht in diesem Zusammenhang der Ticketnummer in unserem Projektmanagementsystem und die Wörter dahinter sind eine kurze Beschreibung dessen, woran gearbeitet wird. Fehlerbehebungen werden ähnlich benannt, bug/20-bug-name.

Jeder erstellte Branch wird zuerst in unseren Staging-Branch gemergt und dann, sobald er vom Kunden genehmigt oder von mir getestet wurde, in den Master-Branch gemergt. Dieser Workflow kann wie folgt aussehen.

# Merge-Funktion in den Staging-Zweig

git merge feature/32-new-feature

# Stellen Sie die Funktion bereit und testen Sie sie

git checkout main

git merge feature/32-new-feature

# Funktion auf der Live-Site bereitstellen

In meinen Projekten habe ich Continuous Deployment eingerichtet, was bedeutet, dass jedes Mal, wenn ich Code auf die Hauptseite schiebe, er automatisch auf die Live-Site gepusht wird. Der gleiche Prozess wird für den Staging-Zweig eingerichtet.

Wenn ich mit einem Team arbeiten würde, das meinen Code in einem Pull-Request-Workflow überprüfen könnte, dann würde ich dieses System verwenden, weil es in einem Team gut funktioniert. Für einen Entwickler, der hauptsächlich alleine arbeitet, ist es einfach der Verwaltungsaufwand, der Ihren Arbeitsablauf verlangsamt.

Fortgeschrittene Git-Befehle, die ich verwende

Nachdem wir nun eine Vorstellung davon haben, wie wir Git in einem praktischen Arbeitsablauf verwenden können, werfen wir einen Blick auf die fortgeschritteneren Befehle, die dazu erforderlich sind. Ich verwende jeden dieser Befehle mindestens ein paar Mal pro Woche, wenn ich mit dem Code meines Kunden arbeite.

Selbst wenn Sie eine GUI-Anwendung verwenden (ich habe einige gute in meinem letzten Beitrag zu Git erwähnt), ist es immer noch wichtig, zu verstehen, was im Hintergrund passiert. Oft musste ich über das Terminal arbeiten, um ein Problem zu beheben, das von einer Git-GUI-Anwendung verursacht wurde.

Änderungen nach Zeile hinzufügen

Der einzige Befehl, der die Git-Nutzung über das Terminal für mich zum Klicken brachte, war git add -p. Bis ich diesen Befehl gelernt habe, habe ich GUI-Anwendungen verwendet, weil ich Änderungen an meinem Code vorgenommen habe, aber bestimmte Zeilen in verschiedene Commits aufteilen wollte, damit ich erklären konnte, warum ich eine Änderung vorgenommen hatte. Dazu habe ich eine GUI verwendet, um die Zeilen auszuwählen, aber git add -p führt Sie durch eine interaktive Schnittstelle, um Änderungen in Blöcken hinzuzufügen.

Ich benutze das jeden Tag viele Male.

Remote-Git-Zweig verfolgen

Wenn Sie ein vorhandenes Repository herunterziehen und Zweige wie main und staging haben, die Sie im Auge behalten müssen, aber bereits vorhanden sind, müssen Sie Ihre lokalen Versionen der Zweige anweisen, diese Remote- Versionen des Zweigs zu verfolgen.

Es gibt einige Möglichkeiten, dies zu tun.

# Upstream setzen, wenn auf Remote gepusht wird

git push -u Origin-Staging

# Stromaufwärts setzen

# setzt voraus, dass Sie sich in dem Zweig befinden, den Sie derzeit mit der Fernbedienung verfolgen möchten

git branch -u Ursprung/Staging

git branch --set-upstream-to=origin/staging

# Wenn Sie nicht auf dem Zweig sind, den Sie verfolgen möchten, geben Sie den Zweig am Ende an

git branch --set-upstream-to=origin/staging staging

Änderungen speichern, ohne sie zu übernehmen

Manchmal befinden Sie sich mitten in einer Arbeit, die noch nicht festgeschrieben werden kann, deren Status Sie jedoch speichern müssen. Hier ist git stash nützlich. Dieser Befehl speichert Änderungen für Sie, indem er die Änderungen entfernt. Sie können sie mit git stash pop wiederherstellen. Es gibt ein paar weitere Befehle, um Stash nützlich zu machen, aber das sind die beiden, die ich regelmäßig verwende.

Ziehen Sie ein bestimmtes Git-Commit

Manchmal müssen Sie einen bestimmten Commit in Ihre aktuelle Arbeit ziehen. Mit einem sauberen HEAD (Sie haben noch keine Änderungen vorgenommen) können Sie einen bestimmten Commit mit git cherry-pick abrufen. Die vollständige Dokumentation zu Git Cherry-Pick finden Sie hier.

Für jeden Commit erstellt Git eine lange Folge von Buchstaben und Zahlen, die als Git-Objekt bezeichnet und allgemein als SHA bezeichnet wird. Da jeder Commit einen bekommt, können Sie einen Commit mit seinem SHA-Wert referenzieren. Lesen Sie mehr über Git-Objekte.

Werfen Sie Änderungen weg, die Sie nicht benötigen

Irgendwann in jedem Projekt werden wir Änderungen vornehmen und dann feststellen, dass es nicht funktioniert und wir sie einfach verwerfen und von vorne beginnen müssen. Anstatt nur zu versuchen, rückgängig zu machen, bis wir wieder da sind, wo wir sein wollen, können wir den folgenden Git-Befehl verwenden, um alle Änderungen zu entfernen, die noch nicht verfolgt wurden.

git reset --hart

Der obige Befehl setzt Ihren Code auf den letzten Commit auf dem Zweig zurück, an dem Sie gerade arbeiten. Wir könnten mit diesem Befehl auch ein <#commitSHA> verwenden, um auf einen bestimmten Commit zurückzusetzen, wenn wir zu einem Zustand vor dem letzten Commit zurückkehren möchten. Vielleicht würden Sie dies verwenden, um auf den anfänglichen Branch-Checkout zurückzusetzen, da Sie nicht den gesamten Branch-Wert der Arbeit behalten möchten, aber einen Teil der Arbeit bereits nachverfolgt haben.

Um noch einen Schritt weiter zu gehen, können wir alle Dateien oder Verzeichnisse, die noch nicht in Git verfolgt wurden, mit dem Befehl git clean wegwerfen.

git clean -fd: Die Flags f und d weisen Git an, Dateien und Verzeichnisse zu verwerfen, die nicht verfolgt werden.

Äste entfernen

Alle ein bis zwei Wochen schaue ich mir die Ergebnisse eines git status-Befehls an und stelle fest, dass ich viel zu viele Zweige habe, um einigermaßen zu verstehen, was in meinem Repository vor sich geht. Das bedeutet, dass ich alle Zweige entfernen kann, die Tickets entsprechen, die mit den folgenden Befehlen aufgelöst wurden.

# entfernt die lokale Version

git branch -d $branchname

#entfernt den Zweig auf meiner Fernbedienung

git push $remotename --delete $branchname

Versionskontrolle verwenden

Auch wenn Sie kein Experte für alle Git-Befehle sind, die Sie verwenden werden, ist es wichtig, daran zu denken, dass Sie die Versionskontrolle verwenden sollten . Selbst wenn Sie die einzige Person sind, die an einem Projekt arbeitet, hilft Ihnen die Verwendung von Git und einem Git-Workflow dabei, Ihre Projekte zu organisieren. Sie müssen STRG + Z nicht drücken, bis Sie Ihre Arbeit zurückgesetzt haben, nachdem Sie Code geschrieben haben, der nicht funktioniert hat.

Sie können Ihrem System vertrauen und weiterhin Arbeit für Ihre Projekte produzieren.

Probieren Sie vollständig verwaltetes WordPress-Hosting aus

Benötigen Sie ein für WordPress optimiertes Hosting? Sehen Sie sich noch heute die vollständig verwalteten WordPress-Hosting-Pläne von Nexcess an.