Vigyázat, hosszú lett. :)
Először definiáljuk a fogalmakat, bár tény, hogy itt a HUP-on sokkal színesebb vita szokott kialakulni, ha ezt nem tesszük meg. :)
Számomra a feature branch egy olyan "long-running" fejlesztői ág, amin egy jelentős méretű fejlesztőcsapat hetekig, hónapokig a mastertől (mainline-tól) elvágva fejleszt valamilyen über-király új feature-t. Ez az, amit károsnak tartok (és az ipari tapasztalatok is ezt mutatják, hogy a skálázódás egyik nagy akadálya, ha ilyen branchokat hozunk létre).
Sajnos a "branch" szó több jelentéssel bír, mivel a verziókezelők egyik funkciója a branchok létrehozása, mint az közismert :)
Az, hogy a fejlesztő csinál a kedvenc verziókezelőjében a következő változtatása számára egy branchot, amit aztán felpushol és egy Pull / Merge Request-hez használ, vagy éppen onnan pushol Gerrit-be szerintem nem "feature branch" a fenti értelemben, hanem a rendelkezésre álló eszközeink normál "state of the art" felhasználása, hiszen pont emiatt használunk elosztott verziókezelőt, hogy a készülő változtatásainkat könnyen kezelhessük egymástól izoláltan.
Annak idején a ClearCase-ben próbálták feloldani ezt a dilemmát, amikor bevezették a Stream fogalmát a Branch mellett, de ez az elnevezés nem terjedt el a szakmában.
Miért káros tehát a long-running feature branch? Nézzük a következő, természetesen kizárólag a képzeletünkben létező történetet.
Adott egy nagyobb termék, aminek az új verziójához jelentős kódmódosításra, refaktorálásra lesz szükség, hogy az új killer feature-t támogassa a rendszer. A szerteágazó változtatások miatt egy long-running feature branchot hoznak létre.
Természetesen úgy indul neki mindenki, hogy majd a masterre érkező módosításokat szépen mergelgetik be a feature branchra. Ez addig működik is, amíg a feature branchon nem túrják át a kódot jelentősen -- de áttúrják, hiszen pont emiatt hozták létre a branchot, hiszen a kis módosítások mehetnének közvetlenül a masterre.
Innentől a mergeljünk a masterről egyre nagyobb kihívás lesz, lelassul a haladás, zuhan a morál (divergáló branchokat szinkronban tartani senki sem szeret). A projektvezető feje elkezd kéken villogni, ahogy csökken a csapat sebessége (a Scrum grafikonokon a napnál is világosabb, hiszen a mergelés nem feature!). A technikai vezető (senior fejlesztő / architekt) egy idő után beadja a derekát: majd visszamergelés előtt egy menetben bemergeljük a master változtatásait.
Ez az a pont, ahol a fejlesztők teljesen felhatalmazva érzik majd magukat arra, hogy a minőségi elvárásokat kicsit könnyítsék: hiába vannak review-k, ha a test coverage csökkenésére vagy a kódban megjelenő hack-ekre az a válasz, hogy majd a visszamergelés előtt megcsináljuk, most haladjunk!
A feature branchon dolgozó fejlesztők nem érzik ugyanazt a fajta (pozitiv) stresszt, mint amikor olyan kódon dolgozol, ami bármikor kimehet élesbe.
Elérkezünk oda, hogy az új feature a branchon nagyjából működik. Természetesen formális system test nem volt rajta, azok a tesztelők a masteren dolgoznak, és nincs is erőforrásuk a feature branchot tesztelni. Nem baj, majd visszamergelés _után_. Merthogy az idő véges, már így is van kisebb-nagyobb (általában nagyobb) az eredeti optimista tervekhez képest.
Tehát megérkezik a parancs: minél hamarabb (ASAP!) vissza kell mergelni a masterre. Jön a masterről mergelés rohammunkában, a remény alapú system teszt (csak nem romlik el semmi!), és megy is vissza az egész masterre.
Ezután, projekt mérettől is függően néhány napra - hétre - hónapra elszabadul a pokol, a master teljesen destabilizálódik, a system teszt csillió hibát jelent, és csak jelentős személyes áldozatok (túlórák) árán lehet újra visszaterelni a fejlesztést a normál ügymenetbe, amíg a következő feature branch meg nem érkezik.
Az ilyen feature branchok nagy csapdája, hogy nem kényszerít rá arra, hogy az új csodafeature-t élesben teszteld, jól elkülöníthető részekre bontsd fel (pl. a korábbi API-t tartsd meg wrapperen keresztül, amíg minden modul át nem állt).
Ez abból a tévhitből is fakad, hogy a verziókezelés a szoftver architektúrától független valami. A valóság ezzel szemben az, hogy a szoftver architektúrája (és build / konfigurációs rendszere) jelentősen behatárolja, hogy a verziókezelés (illetve általában a CM - configuration management) hogyan, milyen eszközökkel valósítható meg.
Pl. részt vettem egy olyan fejlesztésben, ami 5 telephelyen folyt, ClearCase MultiSite alapon, telephelyenként külön branchon. A szoftverben volt 1 db fájl, ami az összes képernyő id-jét tartalmazta. Tehát ezt a fájlt mindenkinek 1000x módosítania kellett. El tudjátok képzelni mi volt ott, minden milestone előtt?
És végül néhány prominens képviselője a single master irányzatnak:
- Linux kernel
- Android
- Google általában (az új belső verziókezelőjükben: "branching is possible but discouraged")
- Facebook
- Windows (amennyit tudni lehet róla)