Trunk-basierte Entwicklung vs. Git Flow

Um qualitativ hochwertige Software zu entwickeln, müssen wir in der Lage sein, alle Änderungen nachzuverfolgen und gegebenenfalls rückgängig zu machen. Versionskontrollsysteme erfüllen diese Rolle, indem sie den Projektverlauf verfolgen und dabei helfen, Änderungen, die von mehreren Personen vorgenommen wurden, zusammenzuführen. Sie beschleunigen die Arbeit erheblich und geben uns die Möglichkeit, Fehler leichter zu finden.

Darüber hinaus ist das Arbeiten in verteilten Teams vor allem dank dieser Tools möglich. Sie ermöglichen es mehreren Personen, gleichzeitig an verschiedenen Teilen eines Projekts zu arbeiten und ihre Ergebnisse später zu einem einzigen Produkt zusammenzuführen. Werfen wir einen genaueren Blick auf Versionskontrollsysteme und erklären, wie Trunk-basierte Entwicklung und Git-Flow entstanden sind.

Wie Versionskontrollsysteme die Welt veränderten

Bevor Versionskontrollsysteme erstellt wurden, verließen sich die Leute darauf, frühere Versionen von Projekten manuell zu sichern. Sie kopierten geänderte Dateien von Hand, um die Arbeit mehrerer Entwickler an demselben Projekt zu integrieren.

Es kostet viel Zeit, Festplattenspeicher und Geld.

Wenn wir uns die Geschichte ansehen, können wir grob drei Generationen von Versionskontrollsoftware unterscheiden.

Werfen wir einen Blick auf sie:

Wir stellen fest, dass mit zunehmender Reife von Versionskontrollsystemen die Möglichkeit besteht, parallel an Projekten zu arbeiten.

Eine der bahnbrechendsten Änderungen war der Wechsel vom Sperren von Dateien zum Zusammenführen von Änderungen. Es ermöglichte Programmierern, effizienter zu arbeiten.

Eine weitere wesentliche Verbesserung war die Einführung verteilter Systeme. Git war eines der ersten Tools, das diese Philosophie verkörperte. Es hat die Open-Source-Welt buchstäblich zum Blühen gebracht. Git ermöglicht es Entwicklern, das gesamte Repository in einer Operation namens Forking zu kopieren und die gewünschten Änderungen einzuführen, ohne sich um Merge-Konflikte kümmern zu müssen.

Später können sie einen Pull-Request starten, um ihre Änderungen in das ursprüngliche Projekt einzufügen. Wenn der ursprüngliche Entwickler nicht daran interessiert ist, diese Änderungen aus anderen Repositories zu integrieren, kann er sie selbst in separate Projekte umwandeln. Das alles ist möglich, weil es kein Konzept für einen zentralen Speicher gibt.

Entwicklungsstile

Das beliebteste Versionskontrollsystem ist heute definitiv Git mit einem Marktanteil von rund 70 Prozent im Jahr 2016.

Git wurde mit dem Aufstieg von Linux und der Open-Source-Szene im Allgemeinen populär. GitHub, derzeit der beliebteste Online-Speicher für öffentliche Projekte, trug ebenfalls erheblich zu seiner Verbreitung bei. Die Einführung einfach zu verwaltender Pull-Requests verdanken wir Git.

Vereinfacht gesagt sind Pull-Requests Anfragen, die von einem Softwareentwickler erstellt wurden, um die von ihm erstellten Änderungen mit dem Hauptprojekt zu kombinieren. Es beinhaltet einen Prozess zur Überprüfung dieser Änderungen. Rezensenten können Kommentare zu jedem Punkt einfügen, den sie für verbesserungswürdig oder unnötig halten.

Nachdem er Feedback erhalten hat, kann der Ersteller darauf antworten, eine Diskussion erstellen oder ihm einfach folgen und seinen Code entsprechend ändern.

Git ist lediglich ein Werkzeug. Sie können es auf viele verschiedene Arten verwenden. Derzeit sind zwei der beliebtesten Entwicklungsstile, denen Sie begegnen können, Git-Flow und Trunk-basierte Entwicklung. Sehr oft sind Menschen mit einem dieser Stile vertraut und vernachlässigen möglicherweise den anderen.

Schauen wir uns beide genauer an und erfahren, wie und wann wir sie verwenden sollten.

Git-Flow

Im Git-Flow-Entwicklungsmodell haben Sie einen Hauptentwicklungszweig mit striktem Zugriff darauf. Es wird oft als develop bezeichnet.

Entwickler erstellen aus diesem Hauptzweig Feature-Zweige und arbeiten daran. Sobald sie fertig sind, erstellen sie Pull-Requests. In Pull-Requests kommentieren andere Entwickler Änderungen und führen möglicherweise Diskussionen, oft ziemlich lange.

Es dauert einige Zeit, bis man sich auf eine endgültige Version der Änderungen geeinigt hat. Sobald man sich darauf geeinigt hat, wird die Pull-Anforderung akzeptiert und mit dem Hauptzweig zusammengeführt. Sobald entschieden wurde, dass der Hauptzweig ausreichend ausgereift ist, um veröffentlicht zu werden, wird ein separater Zweig erstellt, um die endgültige Version vorzubereiten. Die Anwendung aus diesem Zweig wird getestet und Fehlerkorrekturen werden angewendet, bis sie bereit ist, für Endbenutzer veröffentlicht zu werden. Sobald dies erledigt ist, führen wir das Endprodukt mit dem master Branch zusammen und markieren es mit der Release-Version. In der Zwischenzeit können neue Funktionen im Entwicklungszweig develop werden.

Unten sehen Sie ein Git-Flussdiagramm, das einen allgemeinen Arbeitsablauf darstellt:

Einer der Vorteile von Git-Flow ist die strenge Kontrolle. Nur autorisierte Entwickler können Änderungen nach genauer Prüfung genehmigen. Es sichert die Codequalität und hilft Fehler frühzeitig zu beseitigen.

Sie müssen jedoch bedenken, dass dies auch ein großer Nachteil sein kann. Es schafft einen Trichter, der die Softwareentwicklung verlangsamt. Wenn Geschwindigkeit Ihr Hauptanliegen ist, könnte dies ein ernstes Problem sein. Separat entwickelte Funktionen können langlebige Verzweigungen schaffen, die möglicherweise nur schwer mit dem Hauptprojekt kombiniert werden können.

Darüber hinaus konzentrieren sich Pull-Requests auf die Codeüberprüfung ausschließlich auf neuen Code. Anstatt den Code als Ganzes zu betrachten und daran zu arbeiten, ihn als solchen zu verbessern, prüfen sie nur neu eingeführte Änderungen. In einigen Fällen können sie zu einer vorzeitigen Optimierung führen, da es immer möglich ist, etwas zu implementieren, um eine schnellere Leistung zu erzielen.

Darüber hinaus können Pull-Requests zu einem umfangreichen Mikromanagement führen, bei dem der leitende Entwickler buchstäblich jede einzelne Codezeile verwaltet. Wenn Sie erfahrene Entwickler haben, denen Sie vertrauen können, können sie damit umgehen, aber Sie könnten ihre Zeit und Fähigkeiten verschwenden. Es kann Entwickler auch stark demotivieren.

In größeren Organisationen ist die Büropolitik während Pull-Requests ein weiteres Problem. Es ist denkbar, dass Personen, die Pull-Requests genehmigen, ihre Position nutzen, um bestimmte Entwickler gezielt daran zu hindern, Änderungen an der Codebasis vorzunehmen. Sie könnten dies aufgrund mangelnden Vertrauens tun, während einige ihre Position missbrauchen, um persönliche Rechnungen zu begleichen.

Git Flow Vor- und Nachteile

Wie Sie sehen können, ist das Ausführen von Pull-Requests möglicherweise nicht immer die beste Wahl. Sie sollten nur dort eingesetzt werden, wo es angemessen ist.

Wann funktioniert Git Flow am besten?

• Wenn Sie ein Open-Source-Projekt ausführen.
  Dieser Stil stammt aus der Open-Source-Welt und funktioniert dort am besten. Da jeder etwas beitragen kann, möchten Sie sehr strengen Zugriff auf alle Änderungen haben. Sie möchten in der Lage sein, jede einzelne Codezeile zu überprüfen, denn ehrlich gesagt können Sie den Mitwirkenden nicht vertrauen. Normalerweise sind das keine kommerziellen Projekte, daher spielt die Entwicklungsgeschwindigkeit keine Rolle.

• Wenn Sie viele Junior-Entwickler haben.
  Wenn Sie hauptsächlich mit Junior-Entwicklern zusammenarbeiten, möchten Sie deren Arbeit genau überprüfen können. Sie können ihnen mehrere Hinweise geben, wie sie Dinge effizienter erledigen können, und ihnen helfen, ihre Fähigkeiten schneller zu verbessern. Personen, die Pull-Requests akzeptieren, haben eine strenge Kontrolle über wiederkehrende Änderungen, sodass sie eine Verschlechterung der Codequalität verhindern können.

  

• Wenn Sie ein etabliertes Produkt haben.
  Dieser Stil scheint auch gut zu funktionieren, wenn Sie bereits ein erfolgreiches Produkt haben. In solchen Fällen liegt der Fokus in der Regel auf der Anwendungsleistung und der Ladefähigkeit. Diese Art der Optimierung erfordert sehr präzise Änderungen. Normalerweise ist Zeit keine Einschränkung, daher funktioniert dieser Stil hier gut. Darüber hinaus passen große Unternehmen hervorragend zu diesem Stil. Sie müssen jede Änderung genau kontrollieren, da sie ihre Investitionen in Höhe von mehreren Millionen Dollar nicht zunichte machen wollen.

Wann kann Git Flow Probleme verursachen?

• Wenn Sie gerade erst anfangen.
  Wenn Sie gerade erst anfangen, ist Git Flow nichts für Sie. Wahrscheinlich möchten Sie schnell ein minimal brauchbares Produkt erstellen. Das Ausführen von Pull-Requests erzeugt einen enormen Engpass, der das gesamte Team dramatisch verlangsamt. Sie können es sich einfach nicht leisten. Das Problem mit Git-Flow ist die Tatsache, dass Pull-Requests viel Zeit in Anspruch nehmen können. Eine schnelle Entwicklung ist so nicht möglich.

• Wenn Sie schnell iterieren müssen.
  Sobald Sie die erste Version Ihres Produkts erreicht haben, müssen Sie es höchstwahrscheinlich einige Male umstellen, um die Anforderungen Ihrer Kunden zu erfüllen. Auch hier reduzieren mehrere Branches und Pull-Requests die Entwicklungsgeschwindigkeit drastisch und werden in solchen Fällen nicht empfohlen.

• Wenn Sie hauptsächlich mit erfahrenen Entwicklern zusammenarbeiten.
  Wenn Ihr Team hauptsächlich aus Senior-Entwicklern besteht, die schon länger miteinander arbeiten, brauchen Sie das oben erwähnte Pull-Request-Mikromanagement nicht wirklich. Sie vertrauen Ihren Entwicklern und wissen, dass sie Profis sind. Lassen Sie sie ihre Arbeit machen und bremsen Sie sie nicht mit der ganzen Git-Flow-Bürokratie aus.

Trunk-basierter Entwicklungsworkflow

Beim Trunk-basierten Entwicklungsmodell arbeiten alle Entwickler an einem einzigen Zweig mit offenem Zugriff darauf. Oft ist es einfach der master -Zweig. Sie übertragen Code darauf und führen ihn aus. Es ist ganz einfach.

In einigen Fällen erstellen sie kurzlebige Feature-Zweige. Sobald der Code auf ihrem Zweig kompiliert ist und alle Tests bestanden hat, führen sie ihn direkt mit master zusammen. Es stellt sicher, dass die Entwicklung wirklich kontinuierlich ist, und verhindert, dass Entwickler Merge-Konflikte erstellen, die schwer zu lösen sind.

Werfen wir einen Blick auf den Trunk-basierten Entwicklungsworkflow.

Die einzige Möglichkeit, Code bei einem solchen Ansatz zu überprüfen, besteht darin, eine vollständige Überprüfung des Quellcodes durchzuführen. In der Regel halten sich langwierige Diskussionen in Grenzen. Niemand hat eine strenge Kontrolle darüber, was in der Quellcodebasis geändert wird – deshalb ist es wichtig, einen durchsetzbaren Codestil zu haben. Entwickler, die in einem solchen Stil arbeiten, sollten erfahren sein, damit Sie wissen, dass sie die Qualität des Quellcodes nicht beeinträchtigen.

Dieser Arbeitsstil kann großartig sein, wenn Sie mit einem Team erfahrener Softwareentwickler zusammenarbeiten. So können sie schnell und unbürokratisch neue Verbesserungen einführen. Es zeigt ihnen auch, dass Sie ihnen vertrauen, da sie Code direkt in den master Branch einführen können. Entwickler in diesem Workflow sind sehr autonom – sie liefern direkt und werden auf die endgültigen Ergebnisse im Arbeitsprodukt überprüft. Bei dieser Methode gibt es definitiv viel weniger Mikromanagement und Möglichkeiten für Büropolitik.

Wenn Sie andererseits kein erfahrenes Team haben oder ihnen aus irgendeinem Grund nicht vertrauen, sollten Sie sich nicht für diese Methode entscheiden – Sie sollten stattdessen Git-Flow wählen. Es erspart Ihnen unnötige Sorgen.

Vor- und Nachteile der Trunk-basierten Entwicklung

Werfen wir einen genaueren Blick auf beide Seiten der Kosten – die allerbesten und die allerschlechtesten Szenarien.

Wann funktioniert Trunk-basierte Entwicklung am besten?

• Wenn Sie gerade erst anfangen.
  Wenn Sie an Ihrem Minimum Viable Product arbeiten, dann ist dieser Stil perfekt für Sie. Es bietet maximale Entwicklungsgeschwindigkeit bei minimalem Formalismus. Da es keine Pull-Requests gibt, können Entwickler neue Funktionen in Lichtgeschwindigkeit bereitstellen. Stellen Sie nur sicher, dass Sie erfahrene Programmierer einstellen.

• Wenn Sie schnell iterieren müssen.
  Wenn Sie die erste Version Ihres Produkts erreicht haben und feststellen, dass Ihre Kunden etwas anderes wollen, dann überlegen Sie nicht lange und nutzen Sie diesen Stil, um eine neue Richtung einzuschlagen. Sie befinden sich noch in der Explorationsphase und müssen Ihr Produkt so schnell wie möglich ändern können.

• Wenn Sie hauptsächlich mit erfahrenen Entwicklern zusammenarbeiten.
  Wenn Ihr Team hauptsächlich aus erfahrenen Entwicklern besteht, dann sollten Sie ihnen vertrauen und sie ihre Arbeit machen lassen. Dieser Workflow gibt ihnen die Autonomie, die sie brauchen, und ermöglicht es ihnen, ihren Beruf zu beherrschen. Geben Sie ihnen einfach einen Zweck (zu erfüllende Aufgaben) und beobachten Sie, wie Ihr Produkt wächst.

Wann kann Trunk-basierte Entwicklung Probleme verursachen?

• Wenn Sie ein Open-Source-Projekt ausführen.
  Wenn Sie ein Open-Source-Projekt betreiben, ist Git-Flow die bessere Option. Sie brauchen eine sehr strenge Kontrolle über Änderungen und Sie können Mitwirkenden nicht vertrauen. Schließlich kann jeder etwas beitragen. Einschließlich Online-Trolle.

• Wenn Sie viele Junior-Entwickler haben.
  Wenn Sie hauptsächlich Junior-Entwickler einstellen, ist es eine bessere Idee, streng zu kontrollieren, was sie tun. Strenge Pull-Requests helfen ihnen, ihre Fähigkeiten zu verbessern und potenzielle Fehler schneller zu finden.

• Wenn Sie ein Produkt etabliert haben oder große Teams leiten.
  Wenn Sie bereits ein erfolgreiches Produkt haben oder große Teams in einem großen Unternehmen leiten, ist Git Flow möglicherweise die bessere Idee. Sie möchten strenge Kontrolle darüber haben, was mit einem etablierten Produkt im Wert von Millionen von Dollar passiert. Wahrscheinlich sind die Anwendungsleistung und die Ladefähigkeiten die wichtigsten Dinge. Diese Art der Optimierung erfordert sehr präzise Änderungen.

Verwenden Sie das richtige Werkzeug für den richtigen Job

Wie ich bereits sagte, ist Git nur ein Werkzeug. Wie jedes andere Werkzeug muss es angemessen eingesetzt werden.

Git-Flow verwaltet alle Änderungen über Pull-Requests. Es bietet eine strenge Zugriffskontrolle auf alle Änderungen. Es eignet sich hervorragend für Open-Source-Projekte, große Unternehmen, Unternehmen mit etablierten Produkten oder ein Team unerfahrener Junior-Entwickler. Sie können sicher überprüfen, was in den Quellcode eingeführt wird. Andererseits kann es zu umfangreichem Mikromanagement, büropolitischen Auseinandersetzungen und einer deutlich verlangsamten Entwicklung kommen.

Trunk-basierte Entwicklung gibt Programmierern volle Autonomie und drückt mehr Vertrauen in sie und ihr Urteilsvermögen aus. Der Zugriff auf den Quellcode ist kostenlos, daher müssen Sie Ihrem Team wirklich vertrauen können. Es bietet eine hervorragende Softwareentwicklungsgeschwindigkeit und reduziert Prozesse. Diese Faktoren machen es perfekt, wenn Sie neue Produkte entwickeln oder eine bestehende Anwendung in eine völlig neue Richtung lenken. Es wirkt Wunder, wenn Sie hauptsächlich mit erfahrenen Entwicklern zusammenarbeiten.

Wenn Sie jedoch mit Junior-Programmierern oder Personen arbeiten, denen Sie nicht vollständig vertrauen, ist Git Flow eine viel bessere Alternative.

Ausgestattet mit diesem Wissen hoffe ich, dass Sie den Workflow wählen können, der perfekt zu Ihrem Projekt passt.