Czym różnią się podejścia Trunk-Based Development i Feature Branching?

Kryterium	Rozwój oparty na trunk (TBD)	Branching funkcji (FB)
Główny gałąź	Jedna główna gałąź (trunk/main/master)	Kilka długotrwałych gałęzi (develop, release, master)
Częstotliwość scalania	Bardzo często (minimum raz dziennie)	Rzadko (po zakończeniu funkcji)
Rozmiar gałęzi funkcji	Bardzo krótkotrwałe (od kilku minut do godzin)	Długotrwałe (od dni do tygodni)
Integracja	Ciągła integracja (CI) jest kluczowa	Integracja zdarza się rzadziej, może być trudniejsza
Ryzyko konfliktów	Mniejsze duże konflikty, ale więcej drobnych i częstych	Większe konflikty przy scalaniu dużych gałęzi
Czas wypuszczenia na produkcję	Szybkie i częste (dostarczanie ciągłe)	Wolniejsze i rzadsze
Wymagania dotyczące testów	Wysoki poziom automatyzacji testów	Testy mogą być wykonywane później w cyklu
Rozmiar zespołu	Lepsze dla małych i średnich zespołów, ale skalowalne z dyscypliną	Dobrze dla dużych zespołów

Rozwój oparty na trunk:

• Skupia się na częstej integracji małych zmian bezpośrednio w głównym branchu.
• Wymaga ścisłej dyscypliny, zautomatyzowanych testów i flag funkcji do zarządzania niekompletnymi funkcjami.
• Zmniejsza ryzyko związane z dużymi scaleniami.

Branching funkcji:

• Każda funkcja jest rozwijana w osobnym branchu.
• Scalanie następuje tylko po zakończeniu funkcji.
• Może prowadzić do "zatopienia" zmian i skomplikowanych konfliktów podczas scalania, jeśli branche żyją długo.

Przykład kodu dla TBD (uproszczony):

// Rozwój odbywa się bezpośrednio w main/trunk
public class FeatureA {
    public void doStuff() {
        // Kod funkcji A
    }
}

// Inny deweloper commit'uje prawie jednocześnie w main/trunk
public class FeatureB {
    public void doOtherStuff() {
        // Kod funkcji B
    }
}

Przykład kodu dla FB (uproszczony):

// Deweloper 1 pracuje na branchu feature/A
// git checkout -b feature/A develop
public class FeatureA {
    public void doStuff() {
        // Kod funkcji A
    }
}

// Deweloper 2 pracuje na branchu feature/B
// git checkout -b feature/B develop
public class FeatureB {
    public void doOtherStuff() {
        // Kod funkcji B
    }
}

// Po zakończeniu funkcji A, branch jest scalany do develop
// git checkout develop
// git merge feature/A

// Po zakończeniu funkcji B, branch jest scalany do develop
// git checkout develop
// git merge feature/B // Mogą wystąpić konflikty z kodem z feature/A