Branching

[Endyl]

Eredmények

Alap struktúra

Többé-kevésbé a successful modellt próbáljuk követni. Ez alapján a master branchen csak működő, v1.0.0-tól csak élesíthető állapot lehet. Innen ágazik le a develop branch, ahol a fejlesztés történik. Ebbe a két branchbe csak pull requestek által kerülhet kód.

Tényleges fejlesztés issue brancheken történik. Ezek develop-ról (vagy bizonyos tracking issuek esetén egymásról) ágaznak le és a kindulási branchükbe térnek vissza (szükség esetén PR által). Sürgős hibajavítás végezhető master-ről leágaztatott hotfix brancheken, amik review és PR után visszakerülnek master-be. A hotfix változtatások master -> develop merge által kerülnek be a fejlesztői ágba.

Ezeken kívül megengedett ideiglenes, kísérleti branchek létrehozása is. Ha megőrzendő a tartalmuk, akkor cherry-pick (vagy hasonló) módszer segítségével átmozgathatók a megfelelő részek a vonatkozó issue/hotfix branchbe. Igyekezzünk nem telerakni a központi repót kísérleti branchekkel; ha nem muszáj, ne pusholjuk őket; ha meg mégis, akkor ha már nincs szükség rájuk, töröljük. Éppen ezért valaki más kísérleti branchére ne alapozzunk munkát, mert azt a szerzője szabadon törölheti, rebase-elheti, módosíthatja saját belátása szerint.

A release branchek kapcsán még nem jutottunk dűlőre. Vagy közvetlen develop -> master merge és taggelés lesz az élesítés folyamata, vagy ha szükségét érezzük, használunk release brancheket is (ekkor a folyamat: develop -> release, release -> master + tag, master -> develop).

Branch nevek

• Éles verzió: master
• Fejlesztői verzió: develop
• Issue branchek: i-{issue id}-{rovid-leiras}
• Hotfix branchek: h-{issue id}-{rovid-leiras}
• Kísérleti branchek: e-{user name}-{rovid-leiras}
• Ha lesz release branch, akkor: r-{verzio}

Branch hatáskör

Igyekezzünk tartani magunkat az 1 issue, 1 branch felálláshoz. Kivételt képezhetnek ezek az esetek:

• ha külön ezzel a céllal írt kód írása nélkül egy issue megoldása egy másik issue megoldását eredményezi

• két issue megoldása olyan szorosan kapcsolódik egymáshoz, hogy nem praktikus külön-külön megoldani őket

Pull requestek

Védett branchekbe (master, develop) csak pull request és review után kerülhet kód. Akik a reviewt végzik, értsék meg az ellenőrzött módosítást (akár a szerzőnek feltett kérdések által), hogy egy-egy résztvevő ne váljon nélkülözhetetlenné a projekt bizonyos részeinek a fenntartásához (busz faktor és társai). Főleg, mivel side project jelleggel megy a dolog és senki sem kötelezhető a részvételének folytatására.

• [x] #20

---

Felvetések

Volt már erről szó #4-ben és #9-ben, de mivel nem feltétlenül csak ennek a témának szentelt szálak, explicit döntés nem született. Jó lenne mielőbb valamiben megállapodni, hogy ne uralkodjon el a káosz a branchek és a git history területén.

Alap struktúra

A legalapabb a kaktusz modell, ahol kb. a masteren történik a fejlesztés, és a release-eket tagek (és adott esetben onnan leágazó branchek) jelölik. Jelenleg ilyesmi történik.

Illetve előkerült a "sikeres" branching modell @inf3rno által, amiből vagy az egészét, vagy minimum annyit érdemes lehetne használni, hogy egy develop branchen történik a fejlesztés, és csak az élesíthető verzió kerül vissza masterbe, release-ként. A verziók itt is jelölve vannak tagekkel.

Az utóbbinak a menedzselésére jött létre a git flow projekt.

Branch nevek

4-ben @Pepita73 javasolta, hogy {issue típus}_{issue id}_{leiras} legyen a konkrét munkát tartalmazó branchek neve. Szerintem könnyebb lesz az életünk, ha a branch nevébe nem vesszük be a típust, hanem szimplán az i_{issue id}_{leiras} minta alapján nevezzük el őket (a típus meg nyilván van tartva címkeként az issue-n).

Ezen felül javasolnám, hogy (ha szükség van ilyenekre) a kísérletezgetésre használt, eldobható brancheket nevezzük el az exp/[user/]akarmi minta alapján. Így még ha véletlenül, vagy szándékosan be is kerülnek egy ide történő push-ba, egyértelmű lesz a jellegük. Ezeket a brancheket a létrehozójuk kérdés nélkül törölheti, módosíthatja, így a tőle érkezett kifejezett kérés nélkül ne nagyon alapozzunk rájuk munkát.

Branch hatáskör

Szintén #4-ben egyelőre arra az álláspontra jutottunk, hogy a feladatok megoldása az 1 issue -> 1 branch -> 1 PR elv alapján történik, hogy jobban követhető legyen a történet. Ettől akkor térjünk csak el, ha egy másik issue a jelenlegi megoldása miatt (erre írt extra kód nélkül) lezárható, vagy ha a kérdéses issuek együttes megoldása feltétlenül szükséges.

Pull requestek

A fentiek függvényében az "élesnek" számító branchekre (master és adott esetben pl. develop) önhatalmúlag ne commitoljunk vagy merge-öljünk. Készüljön egy PR és a megfelelő számú review (jelenleg 1) után mehet a merge. Aki elvállalja a review-t, az a busz faktor növelése érdekében igyekezzen megérteni a módosításokat. Illetve ha születik végleges megegyezés a fentiekben (vagy bármilyen egyéb, követendő mintában), akkor azok betartására is nyugodtan szólítsa fel a szerzőt.

Várom a véleményeket, szavazatokat! Aztán azok fényében majd szerkesztem (vagy akár más is szerkesztheti) az eredmények részt.

---

Vonatkozó issuek:

• 4

• 9

[ghost]

A nevekkel kapcsolatban szerintem is jobb kihagyni a típust. Legalábbis előfordulhat olyan, hogy question-ként kezdi valami, aztán a végére kiderül, hogy bugot talált az illető. A leírás alatt pontosan mire gondolsz?

Szerintem a kísérletezést ugyanúgy kössük issue-hoz, és lehetne az issue-knál egy experiment tag. Igy elég lenne egy féle branch elnevezést használni, illetve legalább valamilyen szinten tudnánk, hogy mi történik ezeken a branch-eken, ha az illető leírja, hogy mivel kísérletezik.

Nekem jó az 1 branch 1 issue és dev-be mergelés + pull request, ha lezárult az issue. A github issue-knál van ilyen mérföldköves rendszer. Esetleg meghatározhatnánk előre, hogy milyen issue-kat kell megoldani a következő mérföldkőig, aztán ha mind megvan, akkor mehet dev-ből master-be az új release. Igy szerintem elég jól nyomon követhető lenne. Vélemények?

Egyelőre én nem látom, hogy a dev és master branch-ek elkülönítésének mi értelme lenne. A release-elés úgyis tag-hez kötött lesz, nem master commit hook-hoz, szóval sok extrát nem ad. Talán akkor lenne értelme, ha egyszerre több verziót fejlesztenénk több dev branch-el. Erről mit gondoltok?

[Endyl]

Leírás alatt az issuenak valami rövid 1-2 szavas összefoglalására gondoltam, hogy a branch nevéből is lehessen sejteni, hogy miről szólhat. De ez lehet elhagyható is.

A kísérleti brancheket azért nem gondoltam szigorúan issuekhoz kötni, mert így egy már folyamatban lévő issue megoldásához is pusholhatsz külön branchen egy javaslatot, ami ha mégsem válik be, gond nélkül lehet törölni, rebase-elni, stb.

A külön dev és master azt a célt szolgálja, hogy mivel a release minőségű kód --no-ff merge segítségével kerül vissza masterba, ezért biztos lehetsz benne, hogy minden masteren lévő commit egy működő kódbázist eredményez. Ha kaktusszal akarod ezt elérni, akkor vagy squasholsz minden branchet merge előtt vagy ha bevállalod a sima fast forward merge-öt, akkor extra óvatosnak kell lenned, hogy minden commitod működő buildet eredményezzen.

Egyébként szerintem a successful modellnél is írnak több verzió együttes fejlesztéséről. Mondjuk nem hiszem, hogy egy sima weboldalnál erre nagyon szükség lenne.

[ghost]

@Endyl Köszi! Igy már világos mindkettő. Nekem jó, ahogy az elején írtad. Szerintem jó, ha van 1-2 szavas label is, úgy biztosan nem keverjük össze a számokat.

[Endyl]

@inf3rno

Nekem jó, ahogy az elején írtad.

Ez melyik részére vonatkozik? :)

Amúgy nekem szimpatikusabb a git flow szerű felállás. Ha mindenki másnak is, akkor azt is el kéne dönteni, hogy egészében követjük a "successful" modellt, vagy csak a dev-master elkülönítésben.

[Pepita73]

Szerintem majdnem mehet is így a wikibe. :)

Alap struktúra

Jelenlegi munkámban majdnem a "successful"-t követjük, annyi különbséggel, hogy nincs külön relase branch, és ha masterből masterbe kell hotfixelni, akkor röviddel utána jön egy master -> develop merge, ezután az egyes feature branch-ek "gazdái" maguknak tolják be a develop -> xy_feature - be. A szerteágazó merge-eknél fennáll a veszélye, hogy PR-en több diff-et látunk, mint szeretnénk. Tehát szerintem vezessünk be develop-ot, ebből lehet relase-elni és minden további ág ebből és ebbe ágazik. Kivétel csak a nagyon sos hotfix, az jöhet magában masterből / -be.

Branch nevek

Annyiból szeretem a b/f kezdőbetűt, mert általában a bugfix elsőbbséget élvez a feature-rel szemben, és ha ez látszik már a branch nevén is, akkor nem feltétlen kell megkeresni hozzá az issue-t. PR-hez már nyilván kell, szóval felőlem elhagyható. Az i_{issue id}_{leiras} is jó, mondjuk így az i betű felesleges, mert mindig ugyanaz (ha viszont külalakra jobban tetszik, akkor persze legyen). exp/[user/]akarmi : szerintem ez ne issue legyen, hanem különböző branch. Gondoljunk arra is, hogy valaki csak kipróbálni / megmutatni akar valamit, és nem issue-kkal tölteni az idejét. :) Annyi, hogy én a "/" jel helyett pl "-" - et használnék, mert előbbi megkavar (szemre) URL-ben is. Tehát ha "csak játszik", ne legyen kötelező az issue, de legyen kötött branch név.

Branch hatáskör

Copy / paste wikibe. :) Mondjuk kicsit kérdéses, hogy mikor érdemes több issue-t egy branch-en, mert pl #14 - en ha nem oldjuk meg a settings dolgot is, akkor várni kellett volna x időt, míg bemegy masterbe, és akkor lehet származtatni a következő branch-et. Ez csak egy létező példa, szóval kb az adott helyzet mutatja mindig, hogy mi az optimális. Nyilván ha külön - külön megoldható 2 (több) issue, akkor az a követendő.

Pull requestek

igyekezzen megérteni a módosításokat Khm, szóval szerintem a reviewer ugyanakkora felelősséget vállal, mint a fejlesztő. Szerintem tudja is, hogy mit approve-ol, ne csak igyekezzen. Ha tesztelni nincs ideje manuálisan, szintén saját felelőssége.

Ha bármi github settings-re szükség van, abban kérlek segítsetek, abban nincs rutinom. :)

@inf3rno

Egyelőre én nem látom, hogy a dev és master branch-ek elkülönítésének mi értelme lenne. Szerintem annyi, hogy kényelmesen különül el a fejlesztés a deploy-tól. Amikor épp egy olyan állapot van (develop-on), amit ki szeretnénk (majd) élesíteni, csak betoljuk masterbe és lehet fejleszteni tovább. Majd amikor ráér az "élesítőmester", kirakja, de addig is jöhetnek develop-ba az új cuccok.

Részemről ennyi, @Endyl szerintem mehetne egyből wiki-be az eredmény. (Én meg még lógok a readme update-tel, azt is wikibe (is) kéne.)

[Pepita73]

Ja ez kimaradt, bocsi:

Leírás alatt az issuenak valami rövid 1-2 szavas összefoglalására gondoltam

Én is. ez nagyon hasznos tud lenni.

[Endyl]

Az i_ prefix azért kellhet, hogy a git nehogy commit hashnek nézze a számok miatt, és problémázzon, hogy nincs is ilyen commit. Főleg, ha csak számból állna a branch név.

Annyiból szeretem a b/f kezdőbetűt, mert általában a bugfix elsőbbséget élvez a feature-rel szemben, és ha ez látszik már a branch nevén is, akkor nem feltétlen kell megkeresni hozzá az issue-t.

Azért én nem feltétlenül mernék egy git branch -vva után csak úgy elkezdeni dolgozni egy branchen anélkül, hogy elolvasnám, miről is szól. Az issuekat meg meg lehet címkézni prioritás szerint.

[Pepita73]

Az i_ prefix azért kellhet

Akkor kell, köszi. :)

Azért én nem feltétlenül mernék egy git branch -vva után csak úgy elkezdeni dolgozni

Én sem, de ha lenyitom (weben) a branch listát, vagy PR-k között matatva is egyből látható. De nem jelent akkora pluszt, hogy rugózzunk rajta, lehet az i_ prefix is, úgyis biztosan van hozzá issue, másképp exp-user-akarmi lenne.

Röviden: engem meggyőztél, legyen i_{issue}_{egy két szó}

[Endyl]

A szerteágazó merge-eknél fennáll a veszélye, hogy PR-en több diff-et látunk, mint szeretnénk. Tehát szerintem vezessünk be develop-ot, ebből lehet relase-elni és minden további ág ebből és ebbe ágazik. Kivétel csak a nagyon sos hotfix, az jöhet magában masterből / -be.

Erre nem megoldás ha a még nem pusholt issue brancheket rebase-eljük, ha valami visszakerül masterből developra? A pusholt brancheknél meg vagy belenyugszunk a merge-ökkel tűzdelt historyba, vagy esetleg óvatosan, megbeszélés alapon rebase-elünk master->develop merge-ök után, vagy PR előtt.

[ghost]

@Endyl

Ez melyik részére vonatkozik? :)

Szerintem a i_{issue id}_{leiras}-ra vonatkozott és a külön exp branch-re, meg a dev-master elkülönítésre a kaktusz helyett, de már régen volt. :-)

[ghost]

@Pepita73

Amikor épp egy olyan állapot van (develop-on), amit ki szeretnénk (majd) élesíteni, csak betoljuk masterbe és lehet fejleszteni tovább. Majd amikor ráér az "élesítőmester", kirakja, de addig is jöhetnek develop-ba az új cuccok.

Ez is jogos érv. Nincs elég tapasztalatom az ilyen csapat munkákkal, valszeg azért merült fel. Igy már több értelmét látom a build master meglétének is.

[ghost]

@Endyl Egyetértek Pepitával abban, hogyha már kétféle branch-ünk van (issue/bug vs experiment), akkor egységesítsük valahogy az elnevezést. A kötőjeles változat nekem egyébként jobban tetszik, mint az underscore, mert nem kell shift-et nyomni, és nehezebb elrontani. :D Mit szólnátok a b-27-bugos-a-rendszer és az e-inf3rno-halalcsillag változatokhoz?

[Endyl]

Akkor most "b" vagy "i"? :D De szerintem legyen "i", mert az általánosabb. Egyébként nekem is jó az i-{issue #}-{leiras} és e-{user}-{leiras}.

Akkor nem a teljes "successful" modellt használjuk, hanem csak master/develop, developról i-* branchek fejlesztésre, developról vagy onnan származó i-*-kről e-* branchek kísérletezgetésre, a release egy develop -> master merge és tagelés, hotfixek meg masterről nyíló i-* branchek, amik visszatérnek masterbe (ezután a master -> develop vagy hotfix -> develop merge van?)?

Ha viszont teljes egészében használnánk, akkor szükség lenne r-{verzio} release és h-{issue #}-leiras hotfix branchekre is.

[Pepita73]

Jó az 'i' , mert így lehet eladni feature nek a bugot.  :-D Az is jó, hogy minden kötőjel, mindegy, csak egységes Legyen. 

"amik visszatérnek masterbe (ezután a master -> develop vagy hotfix -> develop merge van?)?"

Master -》develop szerintem tisztább szárazabb érzés. 

Elnézést, de már vonaton vagyok, holnap tudok rá nézni többire. 

Üdvözlettel: Horváth Péter

(Mobilról)

(mail kliens szemét törölve)

[ghost]

@Endyl Ja bocs, leragadtam ott, hogy legyen külön "b" meg "i", de ja, elég az "i".

[ghost]

@Endyl

Akkor nem a teljes "successful" modellt használjuk, hanem csak master/develop, developról i- branchek fejlesztésre, developról vagy onnan származó i--kről e- branchek kísérletezgetésre, a release egy develop -> master merge és tagelés, hotfixek meg masterről nyíló i- branchek, amik visszatérnek masterbe (ezután a master -> develop vagy hotfix -> develop merge van?)?

Ha viszont teljes egészében használnánk, akkor szükség lenne r-{verzio} release és h-{issue #}-leiras hotfix branchekre is.

Ahogy nézem mások cherry pick-el szokták megoldani: https://stackoverflow.com/a/7177396/607033 meg nekem is valami ilyesmi rémlett valahonnan a tudatalattim sötét bugyraiból.

szerk: Hmm érdekes, a commenteket nézve nem biztos, hogy jó nekünk a cherry pick, és talán a master -> dev jobb lehet. Nem igazán értek ilyen mélységekben a git-hez, jobb, ha rátok bízom ezt a részét. Szóval ezt a cherry pick-et vegyétek inkább brain storming-nak.

[Endyl]

A linkelt válaszban azt írják, hogy a cherry-pick (mivel új commitot hoz létre) egy későbbi dev -> master merge-nél conflictot okoz; az annyira nem szerencsés, én inkább kerülném.

A hotfix -> master, master -> dev tűnik a jó kombónak. A hotfix -> master, hotfix -> dev kombóról azt írják git flownál, hogy az sem szerencsés: Why does git-describe not work for me? De most nézem, hogy be is állt az a projekt, és egy forkja van karbantartva jelenleg, ahol a hotfix -> master, master -> dev-et csinálják.

[Pepita73]

A hotfix -> master, master -> dev tűnik a jó kombónak.

Szerintem is, azt gondolom ezt az ágat tisztáztuk. @Endyl , betennéd wikibe az eredményt?

[Endyl]

Megírom majd, csak egy dolgot még tisztázzunk: teljes vagy részleges git flow?

• Teljes:
  • Pro: van kész eszköz, nem kell git mágusnak lenni a branch kezeléshez, a prefixeket is megjegyzi, stb.
  • Kontra: plusz telepítendő csomag (kivéve, ha észben tudod tartani a szükséges parancsokat), plusz két fajta branch
• Részleges:
  • Pro: kevesebb branch, nem kell extra csomagot telepíteni
  • Kontra: érteni kell rendesen a git lelkivilágát, branch kezelést, stb., vagy nekünk kell feltalálni a spanyolviaszt, és egy személyre szabott git flow szkriptgyűjteményt összeállítani

[Pepita73]

Részeges jobb, az kacskaringós. :) Nálunk ez van jelenleg: Piros a master, abba csak akkor megy és csak a develop, ha relase van (kivéve hotfix). Ha az 1-es feature-nek szüksége van a 3-as bugfix-re, akkor megvárja, míg az develop-ba ér és onnan behúzza magához (vagyis: merge develop -> 1)

Szerintem kár külön bajlódni relase branch-ekkel, főleg amíg hárman vagyunk (talán négyen).

[Endyl]

Én csak azért hajlok a teljes felé, mert akkor egy kész, bevált eszközt használunk, nem kell shell szkriptekkel bajlódni (max csinálnánk dummy release brancheket). Plusz most fedeztem fel, hogy a git for windows (2.6.4-től) alapból tartalmazza a "git flow (AVH edition)"-t. Lásd. Úgyhogy a plusz telepítés kontra nem is áll fenn windows esetén :)

[Pepita73]

@Endyl rendben, akkor próbáljuk ki a full -t . Ebben lehet, hogy eleinte segítségre szorulok, hogy mikor mit merre kell kanyarítani, de jó pap és jó fejlesztő holtig tanul. :) 

Üdvözlettel: Horváth Péter

(Mobilról)

[Endyl]

Majd igyekszem összeírni valamit erről is. De valszeg összeszedem majd a sima git parancsokat is, ha valaki azzal akar bűvészkedni. Meg ha nagyon akarjuk, kihagyhatjuk a release branch részét is. A napokban végigpróbálom, hogy mennyire lehet az igényeikre szabni ezt a git flow editiont. Lehet, hogy a kecske is jól lakik, meg a káposzta is megmarad :D

[Endyl]

Írtam összefoglálót; nézzetek rá, ha kell szerkeszzétek. Ha okés, akkor majd keresek neki helyet a wikiben.

[ghost]

@Endyl Oké, de hol van? :-)

[Endyl]

Fent, az eredmények részen :D

[ghost]

@Endyl Ja oké. :D

[Pepita73]

De valszeg összeszedem majd a sima git parancsokat is, ha valaki azzal akar bűvészkedni.

@Endyl , külön megköszönném, mert parancssorból szeretem intézni, viszont valószínű jóval kevesebbet használok, mint amit a git flow kíván.

Nem igazán tudom, hogy most hogy állunk a relase-zel, nem úgy volt, hogy teljes git flow? Akkor ez nem kell, hogy feltételes mód legyen, de próbáld ki nyugodtan a kecskét káposztával, ne ezen múljon a boldogság. :) Ami lett Eredmények, az szerintem teljesen jó és pontos. Annyit esetleg bele lehetne írni (de nem tudom jól megfogalmazni), hogy alapvetően minden i- develop-ból származik és oda tér vissza, h- származhat masterből is, és mindig a forrásába tér vissza, e- származhat bárhonnan, de vagy ugyanoda tér vissza, vagy törölni kell. Masterba nem mehet e-. Illetve még annyi, hogy PR és merge után töröljük a branch-et, amin készült, ezt szerintem a fejlesztője tegye meg (ne jussunk oda, hogy 10+, netán több száz nyitott branch-ünk van).

[Endyl]

Ok!

Ha lesz még kérdés, felvetés, az mehet #27-be.