Csapatmunka zűrzavar nélkül: az elágazási stratégiák megértése a Gitben

Bevezetés

A Git a szoftverfejlesztésben használt verziókezelő rendszerek de facto iparági szabványává vált. Először olvassa el cikkemet arról, hogy mi az a Git, és hogyan kezdje el. Olvastad? Kiváló, induljunk! Akár tetszik, akár nem, ez a Linus Tovalds által létrehozott eszköz nem fog visszavonulni. Tehát érdemes beszélni arról, hogy az elosztott csapatok hogyan működnek együtt a Gittel, és milyen elágazási stratégiát kell ehhez választaniuk. Ez nem lényegtelen kérdés. Egy olyan új fejlesztőcsapat összeállításakor, amely korábban nem dolgozott együtt, gyakran az elágazási stratégia az egyik első döntés. És néhány ember habzik majd, hogy bebizonyítsa, az egyik stratégia jobb, mint a másik. Tehát szeretnék néhány általános információt közölni róluk.

Szükségesek-e az elágazási stratégiák?

Valóban szükségesek. Nagyon szükséges. Mert ha a csapat valamiben nem ért egyet, akkor minden csapattag azt csinál, amit akar:

• bármilyen ágazatban dolgozik
• tetszőleges más ágakba való beolvadás
• néhány ág törlése
• újakat létrehozni
• így minden csapattag egy irányítatlan folyamatban fog cselekedni.

Ezért az alábbiakban három stratégiát kell megfontolni. Gyerünk!

GitHub Flow

Furcsa módon ezt az elágazási stratégiát részesítik előnyben a GitHubon :) Egy sor szabályt tartalmaz :

1. A fő ágban lévő kódot nem szabad feltörni. Bármikor készen kell állnia a telepítésre. Ez azt jelenti, hogy nem szabad olyan kódot elhelyezni, amely megakadályozza a projekt felépítését és a kiszolgálóra történő telepítését.
2. Ha új funkcionalitáson szeretne dolgozni, létre kell hoznia egy új szolgáltatáságat a fő ág alapján, és értelmes nevet kell adnia neki. Végezze el a kódot helyben, és rendszeresen küldje el a módosításokat a távoli tároló ugyanabba az ágába.
3. Nyisson meg egy lehívási kérelmet (a lehívási kérelmekről itt olvashat ), amikor úgy gondolja, hogy a munka készen áll, és beolvasztható a fő ágba (vagy ha bizonytalan, de szeretne visszajelzést kapni az elvégzett munkáról).
4. A lekérési kérelem új funkciójának jóváhagyása után az egyesíthető a fő ágba.
5. Amikor a változtatásokat a fő ágba egyesítik, azonnal telepíteni kell őket a kiszolgálóra.

A GitHub Flow szerint mielőtt valami újon kezdenél dolgozni, legyen az javítás vagy új funkció, létre kell hoznod egy új ágat a master alapján, és megfelelő nevet kell adni neki. Ezután megkezdődik a megvalósítás. Folyamatosan be kell küldenie a véglegesítéseket az azonos nevű távoli szerverre. Ha arra a következtetésre jut, hogy minden készen áll, létre kell hoznia egy lehívási kérelmet a fő ághoz. Ezután legalább egy, de még jobb esetben két embernek meg kell néznie ezt a kódot, mielőtt a „Jóváhagyás” gombra kattintana. Általában a projekt csapatvezetőjének és egy második személynek feltétlenül meg kell néznie. Ezután befejezheti a lehívási kérelmet. A GitHub Flow arról is ismert, hogy folyamatos kézbesítést (CD) biztosít a projektekben. Ennek az az oka, hogy amikor a változtatások a fő ágba kerülnek, azokat azonnal telepíteni kell a kiszolgálóra.

GitFlow

Az előző stratégia (GitHub Flow) lényegében nem túl bonyolult. Kétféle elágazás létezik: fő és jellemző ág. De a GitFlow komolyabb. Legalább a fenti képnek ezt világossá kell tennie :) Szóval hogyan működik ez a stratégia? Általában a GitFlow két állandó ágból és többféle ideiglenes ágból áll. A GitHub Flow kontextusában a fő ág állandó, a többi pedig ideiglenes. Kitartó ágak

• mester: Senki ne nyúljon ehhez az ághoz, ne nyomjon semmit. Ebben a stratégiában a master a legfrissebb stabil verziót képviseli, amelyet a termelésben (vagyis egy valódi szerveren) használnak.
• fejlesztés: A fejlesztési ág. Instabil lehet.

A fejlesztés három ideiglenes segédág segítségével történik :

1. Funkcióágak – új funkciók fejlesztéséhez.
2. Kiadási ágak – a projekt új verziójának kiadására való felkészüléshez.
3. Gyorsjavítási ágak – a valódi felhasználók által valódi szerveren talált hibák gyors kijavításához.

Jellemző ágak

A szolgáltatáságakat a fejlesztők hozzák létre az új funkciókhoz. Ezeket mindig a fejlesztési ág alapján kell létrehozni. Az új funkcióval kapcsolatos munka befejezése után létre kell hoznia egy lehívási kérelmet a fejlesztési ághoz. Nyilvánvaló, hogy a nagy csapatoknak egyszerre több szolgáltatási ága is lehet. Nézd meg még egyszer a képet a GitFlow stratégia leírásának elején.

Engedje el az ágakat

Amikor a fejlesztési ágban elkészült a szükséges új funkciók készlete, felkészülhet a termék új verziójának kiadására. Ebben segítségünkre lesz egy kiadási ág, amely a fejlesztési ág alapján jön létre. Amikor a kiadási ággal dolgozik, meg kell találnia és ki kell javítania az összes hibát. A kiadási ág stabilizálásához szükséges új változtatásokat szintén vissza kell olvasztani a fejlesztési ágba. Ez a fejlesztési ág stabilizálása érdekében történik. Amikor a tesztelők azt mondják, hogy az ág elég stabil egy új kiadáshoz, akkor azt a fő ágba egyesítik. Később egy címke jön létre ehhez a véglegesítéshez, amelyhez verziószámot rendelnek. Példa megtekintéséhez nézze meg a stratégia elején található képet. Itt az 1.0 címke jelenik meg— ez csak egy címke, amely a projekt 1.0-s verzióját jelzi. És végül megvan a gyorsjavítási ág.

Gyorsjavítási ágak

A gyorsjavítási ágak egy új verzió kiadására is szolgálnak a fő ágon. Az egyetlen különbség az, hogy ezeket a kiadásokat nem tervezik. Vannak olyan helyzetek, amikor hibák kerülnek be a kiadott verzióba, és azokat az éles környezetben fedezik fel. Vegyük az iOS-t: amint megjelenik egy új verzió, azonnal kap egy csomó frissítést a kiadás után talált hibák javításával. Ennek megfelelően gyorsan ki kell javítanunk egy hibát és ki kell adnunk egy új verziót. Képünkön ez az 1.0.1-es verziónak felel meg. Az ötlet az, hogy az új funkciók kidolgozásának nem kell leállnia, amikor egy valódi szerveren (vagy ahogy mondjuk, "gyártásban" vagy "termelésben") ki kell javítani egy hibát. A gyorsjavítási ágat a fő ágból kell létrehozni, mivel ez a jelenleg élesben futó ágat képviseli. Amint a hibajavítás készen áll, beolvasztja a masterbe, és létrejön egy új címke. Csakúgy, mint egy kiadási ág előkészítése, a gyorsjavítási ágnak is vissza kell egyesítenie a javítását a fejlesztési ágba.

Elágazó munkafolyamat

A forking munkafolyamatban a fejlesztés két adattárat foglal magában:

1. Az eredeti tárház, amelybe az összes módosítás beolvasztásra kerül.
2. Egy villa tároló. Ez az eredeti tár másolata, egy másik fejlesztő tulajdonában, aki módosítani akarja az eredetit.

Eddig kicsit furcsán hangzik, igaz? Aki találkozott már nyílt forráskódú fejlesztéssel, az már ismeri ezt a megközelítést. Ez a stratégia a következő előnyökkel jár: a fejlesztés egy fork repository-ban történhet anélkül, hogy az eredeti ágban közös fejlesztésre engedélyt adna. Természetesen az eredeti adattár tulajdonosának joga van a javasolt változtatásokat elutasítani. Vagy elfogadni és összevonni őket. Ez kényelmes mind az eredeti tároló tulajdonosa, mind a fejlesztő számára, aki segíteni szeretne a termék létrehozásában. Például javasolhat változtatásokat a Linux kernelen . Ha Linus úgy dönt, hogy ezeknek van értelme, a változtatások hozzáadódnak (!!!).

Példa a forking munkafolyamatra

A forking munkafolyamat akkor kerül alkalmazásra a GitHubon, ha van egy használni kívánt könyvtár. Van egy hibája, amely megakadályozza, hogy teljes mértékben használja. Tegyük fel, hogy elég mélyre merül a problémában, és ismeri a megoldást. Az elágazó munkafolyamat használatával a probléma a könyvtár eredeti tárházában való munkavégzés joga nélkül javítható. A kezdéshez ki kell választania néhány adattárat, például a Spring Framework- et. Keresse meg és kattintson a "Villa" gombra a jobb felső sarokban: Ez eltart egy ideig. Ezután az eredeti adattár másolata megjelenik a személyes fiókjában, amely jelzi, hogy ez egy villa:Most már a szokásos módon dolgozhat ezzel a tárolóval, változtatásokat adva hozzá a fő ághoz, és amikor minden készen van, létrehozhat egy lehívási kérelmet az eredeti tárolóhoz. Ehhez kattintson az Új lekérési kérelem gombra:

Melyik stratégiát válasszuk

A Git egy rugalmas és hatékony eszköz, amellyel a folyamatok és stratégiák széles skálájával dolgozhat. De minél több választási lehetősége van, annál nehezebb eldönteni, melyik stratégiát válassza. Nyilvánvaló, hogy nincs mindenki számára egységes válasz. Minden a helyzettől függ. Ennek ellenére több irányelv is segíthet ebben:

1. A legjobb, ha először a legegyszerűbb stratégiát választja. Csak szükség esetén térjen át összetettebb stratégiákra.
2. Fontolja meg azokat a stratégiákat, amelyek a lehető legkevesebb ágtípust tartalmazzák a fejlesztők számára.
3. Tekintse meg a különböző stratégiák előnyeit és hátrányait, majd válassza ki a projektjéhez szükségeset.

Ennyit akartam mondani a Git elágazási stratégiáiról. Köszönöm a figyelmet :) Kövess engem a GitHubon , ahol gyakran teszem közzé alkotásaimat különböző technológiák és eszközök felhasználásával, amelyeket a munkám során használok.