Git - 4. Branching model, feature branching

Ha egyszer végetér a magánprojektek világa és többen fogtok egy nagy projekten dolgozni, valamilyen szempontok mentén használnotok kell a verziókezelőt. Itt egy közismert branching modelt mutatok be és beszélünk a feature branchingről is.

Elmélet

Master és develop

Legegyszerűbb esetben is két verziója van egy még támogatott projektnek: van egy éles verzió, amit az ügyfelek/felhasználók kapnak meg. Ez jól ki van tesztelve, figyelünk rá, hogy minél kevesebb hiba legyen benne. Van emellett egy olyan verzió, ami fejlesztés alatt áll. Ezt csak a fejlesztők (esetleg tesztelők) nyomogatják, ide mennek be a fejlesztések és innen kerülnek majd át az éles verzióba.

Ez eddig egy master és egy develop branch.

A fejlesztést a develop branchben végezzük, a befejezett fejlesztéseket pedig itt teszteljük. Ha megfelelnek az igényeknek, mergeljük őket a master branchbe - nyilván ott is megnézzük minden oké-e - majd pedig kitesszük az az éles rendszerre. Utóbbi hívjuk deploynak.

A master branchbe való közvetlen commitolást általában le is tiltják ilyen esetben, csak mergelni lehet a master branchbe.

Feature branching

A feature branching a megoldás arra, hogy ne zavarják egymást a fejlesztők, a különböző feature-ök elkészítése közben. A feature tulajdonképpen egy-egy feladat/task/issue, amit el kell végezni. Ez a megoldás úgy működik a legjobban, ha van egy megfelelő ticket manager rendszerünk, pl. Jira, YouTrack vagy Redmine, Kanboard, de akár egy Trello is elég lehet.

A ticket managerek lényege, hogy az elvégzendő feladatokat, hibabejelentéseket összefogják, kapnak egy feladatszámot és egy részletes leírást - egy specifikációt - mit kell teljesíteni.

A fejlesztők magukra teszik a taskokat (vagy rájuk osztja a vezetőjük), ha pedig elkezdenek rajta dolgozni, az első lépésük, hogy létrehozzák a feature branchet a feature/PLD-142_Feladat-rovid-neve formának megfelelően. A PLD-142 a ticket managerben generált neve a tasknak, illetve praktikusan utánaírjuk a task rövid nevét is, hogy szabad szemmel is azonnal érthető legyen, mi készül a branch alatt.

Merge request és a code review

Ott, ahol már feature branching van, nem mergelgetnek csak úgy be mindent a developba, ha az elkészül. A felállás ugye ilyen esetben úgy néz ki, hogy legalább ketten vagytok a projekten, úgyhogy ilyenkor már lehet reviewzni.

Tegyük fel, hogy az említett PLD-142-es taskot kivetted, be is fejezted, szeretnéd, hogy bekerüljön a developba, onnan pedig majd szépen az éles verzióba.

Miután felpusholod a repositoryba a kódodat, egy merge requestet kérsz rá, hogy bemergelje a másik kollégád a developba. Ez a GitLabon például így néz ki:

No, ugye itt nem csak erről van szó, hogy felteszed, ráosztod a kollégára, ő meg egyből rábök a nagy Merge gombra. Itt jön képbe a Code Review.

Code Review

Azaz a kollégád - vagy a vezető fejlesztő - megnézi, hogy mit fejlesztettél. Ha valami problémát talál benne, az adott sort vagy sorokat megjelölve megjegyzéseket írhat hozzá és “visszadobhatja” rád a requestet. Itt vagy megmagyarázod, hogy miért tetted azt, amit kifogásolt, vagy ha egyértelműen problémás amit látott, kijavítod úgy, ahogy kérte.

Ekkor te elvégzed a javítást, pusholod, szólsz neki, nyugtázza. Ha minden oké, be is mergeli a develop branchbe a munkádat és lezárja a requestet. Ha viszont megint talál problémát benne, ismét visszadobhatja. Ez a körforgás addig zajlik, amíg jó nem lesz a kód és rá nem bök a merge gombra.

Így biztosítható az egy nagy projektben, hogy minden fejlesztő megfelelő minőségű kódot tesz a projektbe, illetve így a vezető is mindig naprakész lesz a projekt állapotával kapcsolatban, aminek management szinten is nagy szerepe van. Cserébe persze több idő megy el a review-k miatt.

Bővebben, a Code Review az a folyamat, ahol vagy egy vezető ellenőrzi az alatta dolgozók munkáját vagy a veled egy szinten dolgozó társad nézi a kódodat, hátha észrevesz olyat, ami fölött elsiklottál. A Code Review tehát nem arról szól, hogy valaki szidja majd a munkádat, sokkal inkább arról, hogy egy másik szem is lássa, amit csináltál, hátha talál egy másik, jobb megközelítést, amit megvitathattok és ez alapján még jobb kód készülhet.

Egymásra épülő feature-ök

Előfordulhat, hogy több olyan feature készül párhuzamosan, amik valahol majd összeérnek, pl. egy közös elemet fognak meghívni, vagy egy közös keretbe kerülnek be, stb.

Ilyenkor több megoldás is elérhető.

Egyrészt a külön részek bemehetnek külön, az összekapcsolás nélkül. Ekkor készítünk még egy feladatot az ticketing rendszerben az összekötésre, tehát külön feladatként valósítjuk meg. A gond az, hogy előfordulhat, hogy így nem lehet egy adott részt tesztelni, a közös egység nélkül, tehát más folyamatokat blokkolhat így, amíg minden task nem készül el.

Másrészt az is lehet egy megközelítés, hogy a feature-ön elkezd dolgozni a fejlesztő kolléga, majd mielőtt a merge requestet kérné rá, bevárja a másik fejlesztést. A másik fejlesztést ekkor bemergelik a develop branchbe, a fejlesztő, aki várakozott pedig a saját feature branchébe belemergeli a develop branchet. Ekkor egyrészt az esetleges más módosításokhoz hozzá tudja igazítani a fejlesztését, másrészt elkészítheti az összekötést.

Ez leginkább projektmenedzsment kérdés és a feladatok létrehozásánál kell jól tervezni, hogy minimalizálva legyenek az ilyen blokkolások.

Élesítés

A fejlesztéstől függően nagyban eltérhet az élesítés folyamata. Webes, folyamatosan fejlődő projektek esetében általában tényleg csak annyi történik, hogy a develop branchet a masterbe mergelik.

Egyéb esetben, pl. asztali alkalmazásoknál vagy bármi másnál, ahol különböző verziókat tartanak számon, a merge mellé készülnek tagek is, esetleg új branchek az adott verziókhoz kötődően, így afféle snapshotot készítve minden verziónál. Ha például több verziója kap támogatást egy szoftvernek, ha verziónként brancheket készítenek, akkor külön lehet velük dolgozni. Ilyenkor általában az elmúlt X db. verzióba security updateket mergelnek vissza, míg az újabbak megkapják az új funkciókat.