Erweiterte Git-Workflows & Verwendung

Hinweis: Der folgende Artikel hilft Ihnen dabei: Erweiterte Git-Workflows & Verwendung

 Erweiterte Git-Workflows &  Verwendung

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

Git-Workflows

Als ich anfing, Git zu verwenden, dachte ich, ich wüsste, wie man es richtig nutzt. Mein idealer Ansatz bestand darin, alle Änderungen an einer Stelle ohne Zweige vorzunehmen, sie dann in das Repository zu übernehmen und weiterzuarbeiten.

Obwohl es besser war, als keine Versionskontrolle zu verwenden, dauerte es eine Weile, bis mir klar wurde, dass ich nicht den Großteil der von Git bereitgestellten Leistung nutzte. Damit Git für mich funktioniert, brauchte ich eine Strategie zum Verzweigen und Zusammenführen meiner Änderungen.

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

Da Git-Flow jedoch nicht für jedes Szenario geeignet ist, werfen wir einen Blick auf einige andere Methoden, mit denen Sie Ihre Git-Projekte organisieren können, während wir uns damit befassen, einschließlich der Art und Weise, wie ich als Einzelentwickler meine Projekte verwalte.

Git-Flow

Wenn ich mir Git-Flow jetzt ansehe, erkenne ich, dass sich die Softwarelandschaft in den letzten 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, eine Anwendung mehrmals am Tag bereitzustellen. Stattdessen haben Sie wahrscheinlich alle paar Monate oder Wochen eine Hauptversionsnummer erstellt und veröffentlicht, wenn Sie in einem besonders agilen Team waren.

Werfen wir einen Blick darauf, was Git-Flow ist.

In Git-Flow haben zwei Zweige eine unendliche Lebensdauer. Zuerst main, das den Code widerspiegeln sollte, der für die Bereitstellung in Ihrer Live-/Produktionsumgebung bereit ist.

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 im Hauptzweig zusammen und kennzeichnen 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-Zweig kann nur aus dem Entwicklungszweig erstellt werden. Es muss wieder in den Entwicklungszweig eingebunden werden. Bei der Benennung kann es sich um eine beliebige Beschreibung der Funktion handeln, an der Sie arbeiten.

Lesen:  Was ist „401 Error Unauthorized Access“? &...

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

2. Veröffentlichung

Release-Branches werden aus dem Develop-Branch erstellt und müssen wieder in Develop und Main zusammengeführt werden. Sie benennen einen Release-Zweig mit der Release-X-Konvention. In der Praxis bedeutet das normalerweise, dass Sie einen Zweig mit der Release-Nummer benennen, die Sie verwenden möchten, etwa so: release-2.2

Sie verwenden einen Release-Zweig als Möglichkeit, die letzte Vorbereitung für die Veröffentlichung Ihrer Software durchzuführen. Dazu kann es gehören, die Versionsnummer der Dateien zu erhöhen, sicherzustellen, dass Ihre Übersetzungen fertig sind, oder abschließende Codeprüfungen.

3. Hotfix

Der Hotfix-Zweig wird aus dem Hauptzweig erstellt und dient zur Aufnahme von Änderungen, die sofort in der Live-Anwendung bearbeitet werden müssen. Dabei kann es sich um einen Fehler handeln, der behoben werden muss, oder um ein Sicherheitsproblem, das behoben werden muss.

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

Der Hauptgrund dafür, dass Teams Git-Flow jetzt nicht verwenden, ist, dass sich die Art und Weise, wie wir Software veröffentlichen, geändert hat. Statt seltener größere Releases zu veröffentlichen, können Sie eine Änderung an einer Anwendung mehrmals am Tag veröffentlichen. Ich weiß, dass ich die Arbeit mehrmals pro Woche an die Standorte meiner Kunden weiterleite, sobald sie fertig ist. Wir geben keine Versionsnummern für die Website an, wir verbessern sie lediglich ständig.

Der Standard-Git-Flow ist nicht dafür gedacht, dies zu berücksichtigen.

Github-Flow

Die zweite Option, die viele Menschen nutzen, ist Github-Flow.

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

Alle Zweige werden ausgehend vom Hauptzweig mit einem beschreibenden Namen für alles, was Sie gerade tun, erstellt.

Sobald Sie Ihre Änderungen fertig haben, erstellen Sie eine Pull-Anfrage.

Sobald Sie eine Pull-Anfrage eingereicht haben, kann das Team, mit dem Sie zusammenarbeiten, die Änderungen überprüfen und Feedback geben. Wenn die Pull-Anfrage als bereit für die Zusammenführung gilt, wird sie in den Hauptzweig Ihres Projekts zusammengeführt.

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

Wie ich Git-Workflows mit Kundenprojekten verwende

Bei 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 CSS, führt jedoch keine größeren Programmierarbeiten durch. Das heißt, wenn ich mich für den Github-Flow entscheiden würde, würde ich meine Pull-Anfragen ü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. Der Hauptzweig verfolgt den Code, der gerade auf der Produktionsseite ausgeführt wird. Die Staging-Verzweigung verfolgt alles, was auf der Staging-Site getestet wird. Wir verwenden es zum Testen von Änderungen, bevor wir sie auf die Live-Site übertragen.

Lesen:  So stellen Sie einen erfahrenen Python-Entwickler ein [Complete Guide]

Jeder Zweig wird aus dem Hauptzweig erstellt. Neue Funktionen erhalten einen Namen wie diesen: feature/32-new-feature. In diesem Zusammenhang entspricht die Zahl 32 der Ticketnummer in unserem Projektmanagementsystem und die Wörter danach 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 eingebunden und dann, sobald er vom Kunden genehmigt oder von mir getestet wurde, in den Master-Branch eingebunden. Dieser Arbeitsablauf könnte so aussehen.

# Funktion in Staging-Zweig zusammenführen

Git-Merge-Funktion/32-neue-Funktion

# Stellen Sie die Funktion bereit und testen Sie sie

git checkout main

Git-Merge-Funktion/32-neue-Funktion

# Funktion auf der Live-Site bereitstellen

In meinen Projekten habe ich eine kontinuierliche Bereitstellung eingerichtet, was bedeutet, dass jedes Mal, wenn ich Code an die Hauptseite übertrage, dieser automatisch an die Live-Site übertragen 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 im Team gut funktioniert. Für einen Entwickler, der größtenteils alleine arbeitet, ist es einfach der Verwaltungsaufwand, der Ihren Arbeitsablauf verlangsamt.

Erweiterte Git-Befehle, die ich verwende

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

Selbst wenn Sie eine GUI-Anwendung verwenden (ich habe in meinem letzten Beitrag zu Git einige gute erwähnt), ist es dennoch 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 zeilenweise hinzufügen

Der einzige Befehl, der für mich die Git-Nutzung per Terminal-Klick ermöglichte, war git add -p. Bis ich diesen Befehl gelernt habe, habe ich GUI-Anwendungen verwendet, weil ich Änderungen an meinem Code vornahm, 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 es jeden Tag viele Male.

Verfolgen Sie den Remote-Git-Zweig

Wenn Sie ein vorhandenes Repository herunterladen und Zweige wie „Main“ und „Staging“ haben, die Sie im Auge behalten müssen, die aber bereits vorhanden sind, müssen Sie Ihre Versionen der Zweige anweisen, diese Versionen des Zweigs zu verfolgen.

Es gibt mehrere Möglichkeiten, dies zu tun.

# Upstream einstellen, wenn zur Fernbedienung geschoben wird

git push -u origin staging

# Upstream einstellen

# geht davon aus, dass Sie sich in dem Zweig befinden, den Sie aktuell mit Remote verfolgen möchten

git branch -u Ursprung/Staging

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

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

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

Speichern Sie Änderungen, ohne sie zu übernehmen

Manchmal befinden Sie sich mitten in einer Arbeit, die noch nicht zur Übergabe bereit ist, deren Status Sie jedoch speichern müssen. Hier ist Git Stash nützlich. Dieser Befehl speichert Änderungen für Sie, indem er sie entfernt. Sie können sie mithilfe von Git Stash Pop wiederherstellen. Es gibt ein paar Weitere Befehle, um Stash nützlich zu machenaber das sind die beiden, die ich regelmäßig verwende.

Lesen:  Entdecken Sie die Welt der mathematischen Puzzles und Rätsel

Ziehen Sie einen bestimmten Git-Commit

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

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

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

git reset –hard

Der obige Befehl setzt Ihren Code auf den neuesten Commit für den 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 zum ersten Auschecken des Zweigs zurückzukehren, da Sie nicht die gesamte Arbeit im Zweig behalten möchten, Sie aber bereits einen Teil der Arbeit nachverfolgt haben.

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

git clean -fd: Die Flags f und d weisen Git an, nicht verfolgte Dateien und Verzeichnisse wegzuwerfen.

Zweige entfernen

Alle ein oder 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 mit den folgenden Befehlen alle Zweige entfernen kann, die gelösten Tickets entsprechen.

# entfernt die lokale Version

git branch -d $branchname

#entfernt den Zweig auf meiner Fernbedienung

git push $remotename –delete $branchname

Verwenden Sie die Versionskontrolle

Auch wenn Sie möglicherweise kein Experte für alle Git-Befehle sind, die Sie verwenden werden, sollten Sie sich Folgendes unbedingt merken Sie sollten die Versionskontrolle verwenden. Selbst wenn Sie die einzige Person sind, die an einem Projekt arbeitet, hilft Ihnen die Verwendung von Git und eines Git-Workflows dabei, Ihre Projekte zu organisieren. Sie müssen STRG + Z erst drücken, wenn 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