Drei Ansätze
Sie können eine dieser beliebten Techniken verwenden oder sie als Grundlage für die Erstellung Ihrer eigenen Techniken verwenden.
GitHub Flow . Die Strategie wird vom GitHub-Serviceteam verwendet. Die Hauptanforderungen sind wie folgt:
- Der Code in der Hauptniederlassung enthält keine Fehler und sollte jederzeit einsatzbereit sein.
- Um mit der Entwicklung eines neuen Features zu beginnen, müssen Sie einen Feature-Zweig im Hauptzweig erstellen und ihm einen Namen geben, der für alle offensichtlich ist. Wenn die Arbeit fertig ist, muss sie über eine Pull-Anforderung in den Hauptzweig eingefügt werden.
- Nach dem Zusammenführen der Änderungen müssen Sie sie sofort auf dem Server bereitstellen.
Dieser Ansatz wird normalerweise für Produkte mit einer einzelnen Version verwendet, die nicht sehr oft aktualisiert wird. Zum Beispiel Websites. Auf der positiven Seite erleichtert dieser Ansatz Entwicklern das Verständnis und die Organisation ihrer Arbeit. Der Hauptnachteil ist, dass es besser ist, eine andere Strategie zu verwenden, wenn Ihr Projekt komplex genug ist und häufig aktualisiert wird.
GitFlow . Es sollte sofort gesagt werden, dass diese Strategie umstritten ist. Es gibt viele positive und negative Bewertungen über sie.
Das Endergebnis ist wie folgt. Es gibt zwei Arten von persistenten Zweigen: den Hauptzweig, um zu verstehen, wie die neueste aktuelle Version aussieht, und den Entwicklungszweig, in dem die Entwicklung stattfindet. Es gibt drei Arten von temporären Zweigen.
- Feature, um neue Features hinzuzufügen. Nach Abschluss der Arbeit müssen Sie im Entwicklungszweig eine Pull-Anfrage erstellen.
- Release, um an neuen Versionen zu arbeiten. Es ist wichtig, dem Titel eine Versionsnummer hinzuzufügen. Dies hilft Ihnen, Verwirrung zu vermeiden und Änderungen zu verfolgen.
- Hotfix für schnelle Fehlerbehebungen.
Dieser Ansatz gilt als einer der besten für Projekte, bei denen ständig mehrere Versionen für verschiedene Plattformen entwickelt werden.
2010 wurde ein Text des niederländischen Programmierers Vincent Driessen " Ein erfolgreiches Git-Verzweigungsmodell " veröffentlicht, in dem er erstmals über GitFlow sprach. Der Artikel wurde sehr beliebt, eine russische Übersetzung erschien und die Methode wurde von vielen Teams übernommen.
Im Jahr 2020 veröffentlichte der amerikanische Programmierer George Stoker einen Artikel „ Bitte hören Sie auf, Git Flow zu empfehlen", Wo er die Methode als veraltet und ineffektiv in modernen Realitäten kritisierte. Als Antwort darauf ergänzte Driessen seinen Text von 2010 mit einem Haftungsausschluss, in dem er zugab, dass seine Methode kein Allheilmittel, sondern nur eine der Möglichkeiten zur Organisation der Arbeit war.
Forking-Workflow. Hier ist der Ansatz wie folgt: Es gibt ein Original-Repository zum Zusammenführen aller Änderungen und eine Kopie davon, in der ein anderer Entwickler arbeitet. Der Ansatz ist der Open-Source-Ideologie sehr nahe, sein Ziel ist es, alle Vorteile der Open-Source-Community innerhalb des Projekts zu nutzen. Der größte Teil des Verzweigungsworkflows kopiert jedoch GitFlow. Feature-Zweige werden hier mit lokalen Entwickler-Repositorys zusammengeführt. Somit wird die Entwicklung auch für sehr große Teams mit Auftragnehmern flexibel.
Zu denen, die diesen Ansatz verfolgen, gehört Linux . Sie können Ihre eigenen Optionen zum Ändern des Codes auch für den Systemkern anbieten. Und dieser Ansatz scheint effektiv zu funktionieren.
Allgemeine Punkte
Unabhängig davon, für welches Konzept Sie sich entscheiden, gibt es grundlegende Punkte, an die Sie sich am besten halten sollten. Hier sind zum Beispiel die Microsoft-Regeln :
- Machen Sie Ihre Filialstrategie nicht zu kompliziert.
- Verwenden Sie Feature-Zweige für alle Updates und Fehlerbehebungen.
- Zusammenführen von Feature-Zweigen zu Hauptzweigen mithilfe von Pull-Anforderungen;
- Halten Sie die Qualität des Upstreams auf dem neuesten Stand.
Eine auf diesen Ideen basierende Strategie führt Ihr Team dazu, mit logischen und leicht verständlichen Versionen zu arbeiten.
Hier sind einige weitere hilfreiche Richtlinien.
Nennen wir es einfach und offensichtlich
Dies hilft allen Teammitgliedern, richtig zu verstehen, wer an was arbeitet. Es ist auch akzeptabel, zusätzliche Informationen in den Filialnamen aufzunehmen, z. B. den Namen des Erstellers. Dies ist der Fall, wenn Sie sich nichts Originelles einfallen lassen müssen. Zweignamen wie "Benutzer", "Bugfix", "Feature", "Hotfix" sind das, was Sie brauchen. Verwenden Sie für verzögerte Zweige separate Spezialflags. Auf diese Weise kann das Team sofort verstehen, worum es geht, und diese Aufgaben immer langfristig im Auge behalten.
Zusammenführen von Zweigen nur durch eine Pull-Anforderung
Der Pull-Request-Mechanismus hat sich als logisch und gut durchdacht erwiesen. Da dieser Prozess einige Zeit in Anspruch nimmt, müssen Sie im Team vereinbaren, was und in welchem Zeitraum von allen Teilnehmern an der Pull-Anfrage erwartet wird. Weisen Sie die Verantwortlichkeiten der Prüfer zu und teilen Sie diese über die interne Wissensbasis mit dem Team.
Hier sind einige spezifische Tipps:
- Laut Microsoft-Untersuchungen beträgt die optimale Anzahl von Überprüfern zwei.
- Wenn Ihr Team bereits die Prinzipien der Codeüberprüfung formuliert hat, halten Sie sich an diese und versuchen Sie, nicht zu brechen.
- Eine Pull-Anfrage funktioniert viel besser, wenn mehr Teammitglieder regelmäßig mit der Überprüfung des Codes beauftragt werden.
- Hinterlassen Sie ausreichend detaillierte Beschreibungen Ihrer Arbeit, damit die Prüfer den Kontext schnell erfassen können.
Richten Sie Zweigrichtlinien ein
Es lohnt sich aus mehreren Gründen, Zeit mit Verzweigungsrichtlinien zu verbringen:
- Auf diese Weise können Sie aktuelle Arbeiten von abgeschlossenen Arbeiten innerhalb des Hauptzweigs isolieren.
- angemessene Einschränkungen vornehmen, indem festgelegt wird, wer und welche Änderungen an bestimmten Branchen vorgenommen werden können;
- schnelle Verbreitung effektiver Arbeitsmethoden.
Es gibt zwei Grundregeln, auf deren Grundlage Richtlinien konfiguriert werden sollten:
- Prüfer werden zum Zeitpunkt ihrer Erstellung automatisch zu einer Pull-Anfrage hinzugefügt. Sie können zuerst eine Liste von ihnen definieren und dann bearbeiten, während Sie gehen;
- Ein erfolgreicher Build ist erforderlich, um die Pull-Anforderung abzuschließen. Code, der in den Hauptzweig gegossen wird, sollte sauber aufgebaut sein.
Das wichtigste Prinzip bei der Erstellung Ihrer Branchenstrategie ist jedoch Folgendes: Sie müssen darüber nachdenken, damit das Team keine Fragen zur Bedeutung dieser oder jener Aktion hat. Dann wird jeder Tag in Ihrem Projekt produktiv sein.
Blog ITGLOBAL.COM - Managed IT, Private Clouds, IaaS, Informationssicherheitsdienste für Unternehmen: