Untersuchen des Featurebranch-Workflows
Die Grundidee hinter dem Featurebranch-Workflow ist, dass die gesamte Featureentwicklung in einem eigenen Branch anstelle des Mainbranches stattfinden soll.
Die Kapselung vereinfacht es mehreren Entwicklern, an einem bestimmten Feature zu arbeiten, ohne die Hauptcodebasis zu stören. Es bedeutet auch, dass der Mainbranch niemals fehlerhaften Code enthält, was ein großer Vorteil für Umgebungen mit Continuous Integration ist.
Die Kapselung der Featureentwicklung ermöglicht auch die Verwendung von Pull Requests, die eine Möglichkeit darstellen, Diskussionen über einen Branch zu starten. Sie ermöglichen es anderen Entwickler*innen, sich gegen ein Feature zu entscheiden, bevor es in das offizielle Projekt integriert wird. Wenn Sie bei einem Feature nicht weiterkommen, können Sie auch ein Pull Request öffnen und Vorschläge von Ihren Kollegen anfordern.
Pull Requests machen es Ihrem Team unglaublich einfach, die Arbeit der anderen zu kommentieren. Außerdem können (und sollten) Featurebranches zum zentralen Repository gepusht werden. Dadurch kann ein Feature mit anderen Entwickler*innen gemeinsam genutzt werden, ohne den offiziellen Code zu berühren.
Da der Mainbranch der einzige „besondere“ Branch ist, stellt die Speicherung mehrerer Featurebranches im zentralen Repository kein Problem dar. Es ist auch eine bequeme Möglichkeit, die lokalen Commits aller Beteiligten zu sichern.
Releasebranchworkflow
Neben dem Featurebranchworkflow wird auch die Releasebranchstrategie häufig in Git-Branchingworkflows verwendet. Diese Strategie umfasst die Erstellung dedizierter Branches speziell für die Releasevorbereitung. Der Releasebranch wird in der Regel aus einem stabilen Featurebranch erstellt und stellt sicher, dass dieser nur gründlich getesteten und validierten Code enthält. Nach der Erstellung durchläuft der Releasebranch zusätzliche Tests, Fehlerbehebungen und Stabilisierungsmaßnahmen, um die Codebasis für die Bereitstellung vorzubereiten. Der Releasebranch ermöglicht die Isolierung releasebezogener Aktivitäten aus der laufenden Featureentwicklung, da er eine kontrollierte Umgebung zum Fertigstellen und Optimieren des anstehenden Release bereitstellt. Nachdem für den Releasebranch alle erforderlichen Anpassungen und Überprüfungen vorgenommen wurden, wird er je nach Releaseprozess des Teams mit dem Mainbranch gemergt oder direkt in der Produktion bereitgestellt. Die Releasebranchstrategie hilft Teams bei der aufwendigen Koordination der Releaseaktivitäten und ermöglicht es ihnen gleichzeitig, einen stabilen Mainbranch für die laufende Entwicklung zu erhalten.
Trunkbasierter Entwicklungsworkflow
Der trunkbasierte Entwicklungsworkflow geht von einem zentralen Repository aus, und der Mainbranch stellt den offiziellen Projektverlauf dar. Anstelle eines direkten Commits in den lokalen Mainbranch erstellen die Entwickler*innen einen neuen Branch, wenn sie mit der Arbeit an einem neuen Feature beginnen. Featurebranches sollten beschreibende Namen wie „new-banner-images“ oder „bug-91“ aufweisen. Die Idee dabei ist, jedem Branch einen klaren, stark fokussierten Zweck zuzuordnen.
Git unterscheidet technisch nicht zwischen dem Mainbranch und den Featurebranches, sodass Entwickler*innen Änderungen an einem Featurebranch bearbeiten, stagen und committen können.
Erstellen einer Verzweigung
Wenn Sie an einem Projekt arbeiten, werden Sie zu einem bestimmten Zeitpunkt viele verschiedene Features oder Ideen in Arbeit haben, von denen einige schon fertig sind und andere noch nicht. Die Verzweigung hilft Ihnen, diesen Workflow zu verwalten. Wenn Sie einen Branch in Ihrem Projekt erstellen, erhalten Sie eine Umgebung, in der Sie neue Ideen ausprobieren können.
Zusätzlich zu Branches für neue Features oder Fixes erstellen Teams, die einem Releasebranchworkflow folgen, auch dedizierte Branches speziell für die Releasevorbereitung. Diese Releasebranches werden in der Regel von stabilen Featurebranches abgeleitet, um sicherzustellen, dass sie gründlich getesteten und validierten Code enthalten. Nach der Erstellung durchläuft der Releasebranch zusätzliche Tests, Fehlerbehebungen und Stabilisierungsmaßnahmen, um die Codebasis für die Bereitstellung vorzubereiten.
Hinzufügen von Commits
Sobald Ihr Branch erstellt wurde, können Sie mit den Änderungen beginnen. Immer wenn Sie eine Datei hinzufügen, bearbeiten oder löschen, führen Sie einen Commit durch und fügen ihn Ihrem Branch hinzu.
Durch das Hinzufügen von Commits können Sie Ihren Fortschritt bei der Arbeit an einem Featurebranch verfolgen.
Commits erzeugen zudem eine transparente Chronik Ihrer Arbeit, die andere einsehen können, um Ihr Vorgehen und die Gründe dafür zu verstehen.
Jedem Commit ist eine Commitnachricht zugeordnet, die erläutert, warum eine bestimmte Änderung vorgenommen wurde.
Außerdem wird jeder Commit als separate Einheit der Änderung betrachtet. So können Sie Änderungen rückgängig machen, wenn ein Fehler gefunden wird oder Sie sich für eine andere Richtung entscheiden.
Commitnachrichten sind wichtig, insbesondere, da Git Ihre Änderungen nachverfolgt und sie dann als Commits anzeigt, nachdem sie an den Server gepusht wurden.
Durch das Verfassen klar formulierter Commitnachrichten können Sie es anderen leichter machen, Ihre Arbeit nachzuvollziehen und Feedback zu geben.
Erstellen eines Pull Requests
Mit Pull Requests beginnen Sie eine Diskussion über Ihre Commits. Da sie eng mit dem zugrundeliegenden Git-Repository integriert sind, kann jeder genau sehen, welche Änderungen zusammengeführt werden, wenn sie Ihre Anforderung annehmen.
Sie können ein Pull Request jederzeit während des Entwicklungsprozesses in folgenden Situationen öffnen:
- Sie verfügen über wenig oder gar keinen Code, möchten aber Screenshots oder allgemeine Ideen mit anderen teilen.
- Sie kommen nicht weiter und brauchen Hilfe oder Rat.
- Sie sind bereit, Ihre Arbeit von jemandem überprüfen zu lassen.
Verwenden Sie das @mention-System in Ihrer Pull Request-Nachricht, um Feedback von bestimmten Personen oder Teams einzuholen, unabhängig davon, ob diese in der Nähe oder 10 Zeitzonen entfernt sind.
Pull Requests helfen bei der Mitarbeit an Projekten und bei der Verwaltung von Änderungen an freigegebenen Repositorys.
Wenn Sie ein Modell vom Typ „Fork und Pull“ verwenden, bieten Pull Requests eine Möglichkeit, die Projektbetreuer*innen über die Änderungen zu informieren, die sie berücksichtigen sollen.
Wenn Sie ein freigegebenes Repositorymodell verwenden, helfen Pull Requests bei der Überprüfung des Codes und der Diskussion über vorgeschlagene Änderungen, bevor diese in den Mainbranch eingefügt werden.
Besprechen und Überprüfen Ihres Codes
Nachdem ein Pull Request geöffnet wurde, kann die Person oder das Team, die bzw. das Ihre Änderungen überprüft, Fragen oder Kommentare haben.
Vielleicht entspricht der Codierungsstil nicht den Projektrichtlinien, es fehlen Komponententests für die Änderung, oder vielleicht sieht alles hervorragend aus, und die Eigenschaften sind in Ordnung.
Pull Requests sind dazu gedacht, diese Art von Konversation zu fördern und festzuhalten.
Sie können auch weiterhin in Ihren Branch pushen und dabei Diskussionen und Feedback zu Ihren Commits berücksichtigen.
Wenn jemand kommentiert, dass Sie etwas vergessen haben, oder wenn es einen Fehler im Code gibt, können Sie dies in Ihrem Branch beheben und die Änderung hochladen.
Git zeigt Ihre neuen Commits und alles Feedback, das Sie erhalten haben, in der vereinheitlichten Ansicht für Pull Requests an.
Pull Request-Kommentare sind in Markdown geschrieben, sodass Sie Bilder und Emojis einbetten, vorformatierte Textblöcke und weitere einfache Formatierungen verwenden können.
Bereitstellen
Mit Git können Sie von einem Branch aus endgültige Tests in einer Umgebung durchführen, bevor die Zusammenführung im Mainbranch erfolgt.
Sobald Ihr Pull Request geprüft wurde und der Branch Ihre Tests bestanden hat, können Sie Ihre Änderungen bereitstellen, um sie zu überprüfen. Wenn Ihr Branch Probleme verursacht, können Sie für ihn ein Rollback durchführen, indem Sie den bestehenden Mainbranch bereitstellen.
Zusammenführen
Nachdem Ihre Änderungen überprüft wurden, ist es an der Zeit, Ihren Code mit dem Mainbranch zusammenzuführen.
Nach dem Zusammenführen bewahren Pull Requests eine Aufzeichnung der historischen Änderungen an Ihrem Code. Da sie durchsuchbar sind, kann jeder zu einem früheren Zeitpunkt wechseln, um zu verstehen, warum und wie eine Entscheidung getroffen wurde.
Sie können Issues mit Code verknüpfen, indem Sie bestimmte Schlüsselwörter in den Pull Request-Text einfügen. Wenn Ihr Pull Request zusammengeführt wird, können die zugehörigen Probleme ebenfalls geschlossen werden.
Mit diesem Workflow können Branches organisiert und nachverfolgt werden, die sich auf Featuresätze für Geschäftsdomänen konzentrieren.
Andere Git-Workflows wie der Git-Fork-Workflow und der Gitflow-Workflow sind repositoryorientiert und können den Git-Featurebranch-Workflow verwenden, um ihre Verzweigungsmodelle zu verwalten.