8. Git (Work)Flow
Indem wir mit Issues arbeiten, verleihen wir unserem Projekt eine elegante Struktur und Übersicht. Die Zuordnung von Aufgaben wird vereinfacht, während jeder Contributor alle notwendigen Informationen erhält, die er benötigt, um seine Aufgabe zu erfüllen. Durch Kommentare und Tags werden alle relevanten Details dabei bereitgestellt.
Sobald ein Issue erfolgreich gelöst wurde, kann es geschlossen werden und die Arbeit an einem neuen vorgenommen werden. Sollte jedoch jemand unzufrieden mit der Lösung sein, so kann ein geschlossenes Issue erneut geöffnet werden, um durch Kommunikation und Feedback eine Verbesserung herbeizuführen.
Pull Requests stellen eine wichtige Möglichkeit dar, um Funktionalitäten aus einem Feature-Branch in einen stabilen Branch wie den Develop-Branch zu integrieren. Das Zusammenführen von Features in einem stabilen Branch sollte so reibungslos wie möglich verlaufen, da dort viele Funktionen zusammengeführt werden und es deshalb zu Merge-Konflikten oder Bugs kommen kann.
Mit einem Pull Request stellt man deshalb eine Anfrage an das Team, ein Feature in einen Branch zu mergen. Das Team prüft daraufhin die Anfrage und genehmigt sie, wenn alles in Ordnung ist.
Releases in Git sind wichtige Meilensteine im Entwicklungsprozess eines Projekts. Sie markieren den Moment, an dem eine neue Version einer Anwendung oder eines Produkts bereitgestellt wird, die für Endbenutzer verfügbar ist. Dabei müssen die Releases mit Tags versehen werden, welche permanente Marker sind, die die Version einer Anwendung oder eines Produkts identifizieren.
Releases können wichtige Änderungen, Fehlerbehebungen und neue Funktionalitäten enthalten, die im Vergleich zur vorherigen Version hinzugefügt wurden. Deshalb ist wichtig, sie sorgfältig zu planen und zu überwachen, dass sie stabil und funktionsfähig sind.
Durch die Verwendung von Releases kann man auch einfach zu früheren Versionen zurückkehren, falls es Probleme mit einer neuen Version gibt. Darüber hinaus bieten sie auch eine Übersicht über den Fortschritt des Projekts und eine Möglichkeit, wichtige Änderungen und Funktionalitäten nachzuvollziehen.
Unser Workflow ist sehr ähnlich, wenn nicht sogar identisch zu Git-Flow:
Im Mittelpunkt steht der sogenannte „develop“ Branch, der den aktuellen Stand der Entwicklung abbildet. Neben dem „develop“ Branch ist auch der „main“ Branch von zentraler Bedeutung, dieser repräsentiert fertige Produktversionen. Diese beiden Branches sind die einzigen, die beständig sind - also nicht wieder gelöscht werden, nachdem sie ihren Zweck erfüllt haben.
Kleine Features können nicht direkt am „develop“ Branch entwickelt werden, sondern werden in eigene Feature Branches ausgelagert. Beim Zurückführen eines Feature Branches in den „develop“ Branch ist darauf zu achten, dass dieser Branch in der Historie sichtbar bleibt.
Soll ein Release vorbereitet werden, so wird aus dem „develop“ Branch heraus ein „release“ Branch erstellt, wobei dieser Branch immer noch einen Suffix mit der Versionsnummer im Namen erhält (z. B. „release-1.2“). Auf diesem Branch sollten nur noch Bugfixes vorgenommen werden. Ist die Version bereit zur Veröffentlichung, so wird der „release“ Branch auf den „main“ Branch geführt und dort getaggt.