Worin unterscheiden sich die Ansätze des Trunk-Based Development und des Feature Branching?

Kriterium	Trunk-Basierte Entwicklung (TBD)	Feature Branching (FB)
Hauptzweig	Ein Hauptzweig (trunk/main/master)	Mehrere langlebige Zweige (develop, release, master)
Frequenz der Zusammenführungen	Sehr häufig (mindestens einmal am Tag)	Selten (nach Abschluss einer Funktion)
Größe der Feature-Zweige	Sehr kurzlebig (von Minuten bis Stunden)	Langlebig (Tage bis Wochen)
Integration	Kontinuierliche Integration (CI) ist entscheidend	Die Integration erfolgt seltener, kann komplexer sein
Konflikt-Risiko	Weniger große Konflikte, aber mehr kleine und häufige	Mehr große Konflikte beim Zusammenführen großer Zweige
Zeit bis zum Release	Schnell und häufig (kontinuierliche Lieferung)	Langsamer und seltener
Testanforderungen	Hohes Maß an Automatisierung der Tests	Tests können später im Zyklus durchgeführt werden
Teamgröße	Besser geeignet für kleine und mittlere Teams, skalierbar mit Disziplin	Gut geeignet für große Teams

Trunk-basierte Entwicklung:

• Fokus auf häufige Integration kleiner Änderungen direkt in den Hauptzweig.
• Erfordert strenge Disziplin, automatisierte Tests und Feature-Flags zur Steuerung von unfertigen Funktionen.
• Reduziert Risiken bei großen Zusammenführungen.

Feature Branching:

• Jede Funktion wird in einem separaten Zweig entwickelt.
• Die Zusammenführung erfolgt nur nach Abschluss der Funktion.
• Kann zu "Verstopfung" von Änderungen und komplexen Konflikten beim Zusammenführen führen, wenn die Zweige lange leben.

Beispielcode für TBD (vereinfachte Version):

// Entwicklung erfolgt direkt in main/trunk
public class FeatureA {
    public void doStuff() {
        // Code der Funktion A
    }
}

// Ein anderer Entwickler committet fast gleichzeitig in main/trunk
public class FeatureB {
    public void doOtherStuff() {
        // Code der Funktion B
    }
}

Beispielcode für FB (vereinfachte Version):

// Entwickler 1 arbeitet im Zweig feature/A
// git checkout -b feature/A develop
public class FeatureA {
    public void doStuff() {
        // Code der Funktion A
    }
}

// Entwickler 2 arbeitet im Zweig feature/B
// git checkout -b feature/B develop
public class FeatureB {
    public void doOtherStuff() {
        // Code der Funktion B
    }
}

// Nach Abschluss der Funktion A wird der Zweig in develop zusammengeführt
// git checkout develop
// git merge feature/A

// Nach Abschluss der Funktion B wird der Zweig in develop zusammengeführt
// git checkout develop
// git merge feature/B // Konflikte mit Code aus feature/A möglich