Zum Inhalt

Git Strategie

Eine Git-Strategie definiert einen planmäßigen Ansatz für die Nutzung von Git in Softwareentwicklungsprojekten, besonders im Hinblick auf Branching, Merging und Release-Management. Sie bestimmt, wie und wann Branches erstellt, zusammengeführt und verwaltet werden, um Entwicklung, Testing und Auslieferung von Software effizient und fehlerfrei zu gestalten.

Durch eine klare Strategie vereinfacht sich die Teamarbeit, Konflikte reduzieren sich, und der Code-Release-Prozess stabilisiert sich. Eine durchdachte Git-Strategie unterstützt die Implementierung einer Continuous Integration und Delivery (CI/CD) Pipeline, welche automatische Builds, Tests und Deployments ermöglicht.

Sie fördert die Code-Qualität, erleichtert Wartungsarbeiten und beschleunigt die Einführung neuer Features oder Bugfixes.

Hauptzweige

%%{init: {
'theme': 'neutral',
'gitGraph': {'mainBranchName': 'production'}
}}%%
gitGraph TB:
    commit id:"Initial commit ..."
    commit id:"Project structure ..."
    branch development
    commit id:"Commit [ 1 ] ..."
    commit id:"Commit [ N ] ..."
    checkout production
    merge development
    commit id:" Hotfix ..."
Branch Beschreibung
production Dieser Zweig reflektiert den aktuellen Stand, der in der Produktionsumgebung live ist. Alle Commits auf diesem Zweig sollten durch Tests in anderen Umgebungen (wie Development oder Staging) verifiziert worden sein.
development Dient als primärer Integrationszweig für neue Entwicklungen. Neue Features und Bugfixes werden hier zuerst integriert, bevor sie in die Produktionsumgebung überführt werden.

Für die Arbeit mit einem Remote-Repository und die Durchführung der ersten Aktionen können folgende Git-Befehle verwendet werden:

Die Branch klonen

Um das gesamte Repository zu klonen (inklusive des Standardbranchs, üblicherweise main oder master), wird folgender Befehl genutzt:

%%{init: {'theme': 'neutral'}}%%
gitGraph:
    commit id:"Initial commit ..."

git clone https://github.com/eugen-hoppe/example.git

Die URL https://github.com/eugen-hoppe/example.git wird durch die tatsächliche URL des Remote-Repositories ersetzt. Nach dem Klonen befindet man sich standardmäßig im Hauptbranch des Repositories.

Einen neuen Branch erzeugen (development)

Nach dem Wechsel in das Verzeichnis des geklonten Repositories wird ein neuer Branch namens development erstellt und sofort in diesen neuen Branch gewechselt:

git checkout -b development

%%{init: {'theme': 'neutral'}}%%
gitGraph
    commit id:"Initial commit ..."
    branch development

Den ersten Commit machen

Nach Änderungen am Projekt werden diese zunächst zur Staging-Area hinzugefügt und dann committet. Beispiel für das Hinzufügen und Commiten einer Datei namens info.txt:

git add info.txt

%%{init: {'theme': 'neutral'}}%%
gitGraph
    commit id:"Initial commit ..."
    branch development
    commit id:"init dev branch ..."

git commit -m "init dev branch"

Zu origin pushen

Nach dem ersten Commit wird der neue Branch inklusive des Commits zum Remote-Repository (üblicherweise origin genannt) gepusht:

git push -u origin development

Dies setzt origin/development als Upstream-Branch für den lokalen development Branch. Zukünftige Pushes können mit git push durchgeführt werden, solange man im development Branch ist.

Mergen von Branches

Um den development-Branch mit dem main-Branch zu mergen und das Remote-Repository aktuell zu halten, sind folgende Schritte notwendig:

Wechsle zum Hauptbranch

Zuerst wird zum Hauptbranch des lokalen Repositories gewechselt. Wenn dieser main heißt, wird folgender Befehl verwendet:

git checkout main

%%{init: {'theme': 'neutral'}}%%
gitGraph
    commit id:"Initial commit ..."
    branch development
    commit id:"init dev branch ..."
    checkout main

Aktualisiere den Hauptbranch

Der lokale Hauptbranch wird mit dem Remote-Repository synchronisiert, um sicherzustellen, dass er auf dem neuesten Stand ist.

git pull origin main

Dies vermeidet Konflikte und stellt sicher, dass die neuesten Änderungen integriert werden.

%%{init: {'theme': 'neutral'}}%%
gitGraph TB:
    commit id:"Initial commit ..."
    branch development
    commit id:"init dev branch ..."
    checkout main
    commit id:" ..."
    commit id:"other commits ..." tag:"v0.1"
    commit id:" ...."

Merge den development Branch in den Hauptbranch

Der development Branch wird in den main Branch gemergt. Bei Konflikten werden diese manuell gelöst und die Änderungen committet.

%%{init: {'theme': 'neutral'}}%%
gitGraph TB:
    commit id:"Initial commit ..."
    branch development
    checkout development
    commit id:"init dev branch ..."
    commit id:" ..."
    commit
    checkout main
    commit id:" ...."
    commit id:"other commits ..." tag:"v1"
    commit id:" ....."
    merge development

Push die Änderungen zu origin

Nach einem erfolgreichen Merge werden die Änderungen im Hauptbranch zum Remote-Repository gepusht:

git push origin main

Zusammenfassung

Diese Schritte halten sowohl das lokale als auch das Remote-Repository aktuell und integrieren den development Branch erfolgreich in den Hauptbranch. Regelmäßiges Pullen und Pushen minimiert Konflikte und behält den Überblick über Änderungen bei, die von verschiedenen Teammitgliedern durchgeführt werden.

Weitere Branches

Entwicklung und Integration von Features

Feature-Branches erstellen: Für jedes neue Feature oder jeden Bugfix wird vom development-Zweig ein neuer Branch erstellt. Branch-Namen sollten beschreibend sein, z.B. feature/login.

Entwicklung auf Feature-Branches: Die Entwicklung findet auf den Feature-Branches statt. Entwickler sollten regelmäßig Commits machen, um ihren Fortschritt zu speichern.

Pull Requests verwenden: Sobald die Entwicklung eines Features abgeschlossen ist, wird ein PR vom Feature-Branch zum development-Zweig erstellt. Dies ermöglicht Code-Reviews und Diskussionen über die Änderungen.

Merging in development: Nach erfolgreicher Überprüfung und Testung des Codes im Rahmen des PR-Prozesses wird der Feature-Branch in den development-Zweig gemerged. Dieser Schritt sollte idealerweise automatisierte Tests beinhalten, um die Stabilität des development-Zweigs zu gewährleisten.

Release-Prozess

Vorbereitung des Releases: Sobald genügend Features im development-Zweig integriert sind und ein neues Release geplant ist, wird ein Release-Zweig vom development erstellt. Dies kann beispielsweise release/v1.2.0 sein.

Testing und Bugfixing im Release-Zweig: Der Release-Zweig wird genutzt, um letzte Tests durchzuführen und kritische Fehler zu beheben, die während der Entwicklung nicht aufgefallen sind.

Merging in production: Nachdem der Release-Zweig stabil ist und alle Tests bestanden hat, wird er in den production-Zweig gemerged. Dies markiert den offiziellen Release des neuen Standes in der Produktionsumgebung.

Tagging des Releases: Nach dem Merge in production sollte der Stand mit einem Tag versehen werden, der die Release-Version kennzeichnet, z.B. v1.2.0.

Wartung und Hotfixes

Hotfixes: Falls ein kritischer Fehler in der Produktionsumgebung gefunden wird, kann ein Hotfix-Branch direkt vom production-Zweig erstellt werden. Nach der Behebung wird der Hotfix sowohl in production als auch in development gemerged, um sicherzustellen, dass der Fehler in zukünftigen Releases nicht wieder auftritt.

Wiederholung und kontinuierliche Verbesserung

Der Zyklus von Feature-Entwicklung, Integration, Testing und Releases wird kontinuierlich wiederholt, wobei jeder Schritt Möglichkeiten zur Optimierung und Effizienzsteigerung bietet. Diese Strategie fördert eine klare Trennung zwischen Entwicklung, Testing und Produktion, minimiert Risiken bei der Einführung neuer Features und sorgt für eine stabile Produktionsumgebung. Es ist wichtig, dass das Team regelmäßig die Prozesse überprüft und anpasst, um den Workflow weiter zu verbessern.