Git radni tokovi: dalje od main-vs-develop modela

Većina savjeta o Gitovu i dalje postavlja problem kao izbor između dva naziva grana: main ili develop. Taj je okvir stariji nego što izgleda i skriva odluke koje su zapravo važne. “Main nasuprot developu” nikada nije bilo stvarno o nazivima. Bilo je to zamjensko pitanje za tri stvarna: koliko dugo žive vaše grane, koliko je velika svaka serija promjena i koliko često objavljujete? Tim koji dobro odgovori na ta pitanja može isporučivati uz gotovo svaki model grananja. Tim koji na njih odgovori loše mučit će se bez obzira na to kako je organizirano njegovo spremište.

Ovaj vodič prolazi kroz obitelji radnih tokova u uobičajenoj upotrebi — razvoj temeljen na deblu, grane za značajke u stilu GitHub Flowa, grane za izdanja u stilu GitLab Flowa te procese u stilu Git Flowa — a zatim i prekidače značajki, koji u potpunosti mijenjaju pravila igre. Za svaki dio dobivate mehaniku, svakodnevne prakse i iskrene kompromise. Na kraju slijedi okvir odlučivanja koji veličinu tima, učestalost objava i rizik preslikava u početnu preporuku, plus pogreške kojih se vrijedi čuvati. Nijedan model ne pobjeđuje svugdje. Cilj je birati promišljeno, držati grane kratkoga vijeka i povijest razumljivom.

Zašto je okvir main-vs-develop zastario

Model s dvije grane dolazi od Vincenta Driessena i njegova posta “A successful Git branching model” iz 2010. Svakom je spremištu dao dvije trajne grane: main, koji uvijek odražava kod spreman za produkciju, i develop, integracijsku granu na koju su značajke stizale prije izdanja. Pomoćne grane — feature/, release/, hotfix/ — imale su stroga pravila o tome odakle smiju nastati i kamo se moraju spojiti. Za svoje je vrijeme model riješio stvarne probleme: programeri su dobili izolaciju, izdanja su se pripremala bez blokiranja novog rada, a greške u produkciji imale su namjenski kanal.

Problem je u tome što model ugrađuje pretpostavke koje za većinu softvera više ne vrijede. Pretpostavlja zakazana izdanja, pretpostavlja da morate podržavati nekoliko verzija u divljini i pretpostavlja da su duge integracijske grane prihvatljive. Sam je Driessen 2020. dodao osvrt: za softver koji se kontinuirano isporučuje sada preporučuje mnogo jednostavniji tok rada i upozorava da je model postao “dogma ili panaceja” umjesto alat. Atlassianov Git vodič danas Gitflow naziva naslijeđenim radnim tokom koji je teško uskladiti s CI/CD-om.

Dublja je poanta da su nazivi grana smetnja. Varijable koje oblikuju isporuku jesu trajanje grana, veličina serije, ritam objava i tko smije spajati. Model s dvije grane develop čini dugovječnim po defaultu, gura značajke u vlakove izdanja i dopušta mainu da odlutava daleko od onoga što stvarno radi. Svaki radni tok u nastavku bolje je razumjeti kao drukčiji odgovor na te četiri varijable nego kao dijagram naziva grana.

Razvoj temeljen na deblu

Razvoj temeljen na deblu disciplina je spajanja rada u jednu zajedničku granu — deblo, obično main — barem jednom dnevno, često i nekoliko puta. Grane postoje satima, ne tjednima. Svaki programer dijeli svoj rad na male serije, pokreće automatizirane testove i integrira prije nego promjena stigne odlutati. Build poslužitelj provjerava svaki commit, a održavanje zelenog builda zajednička je odgovornost: ako CI pocrveni, netko to odmah popravi ili vrati promjenu.

DORA-ina analiza podataka iz izvještaja State of DevOps za 2016. i 2017. pokazala je da su timovi s tri ili manje aktivnih grana, spajanjem na deblo barem jednom dnevno i bez zamrzavanja koda postizali bolji učinak isporuke. Izvještaji su stari, ali mehanizam nije: česta mala spajanja drže svaku programerovu kopiju blizu stvarnosti, pa integracija prestaje biti faza projekta i postaje dio svakodnevnog ritma.

Svakodnevno, razvoj temeljen na deblu traži navike koje zvuče jednostavno, a zahtijevaju praksu:

Male serije. Promjena koja stane u nekoliko sati rada jest promjena koja se može brzo recenzirati i jeftino vratiti. Naučiti dijeliti značajku na spojive dijelove najteža je vještina u ovom modelu.
Brzi automatizirani testovi. Build bi trebao završiti za nekoliko minuta. DORA je pritom izričita: spor build jest arhitektonski problem, a ne isprika za slijepo spajanje.
Recenzija bez čekanja. Programiranje u paru računa se kao recenzija. Ako koristite zahtjeve za spajanje, tretirajte ih kao kratkotrajne: otvorite ih, recenzirajte sinkrono i spojite isti dan. Asinkrona recenzija koja traje dva dana dugovječna je grana u maski.
Zeleno deblo. Svaki commit trebao bi ostaviti deblo u ispravnom stanju. Prvo vratite, pitanja kasnije.

Objave funkcioniraju na jedan od dva načina. Ako objavljujete nekoliko puta dnevno, objavljujete izravno s debla i označavate commit koji šaljete u produkciju. Ako trebate razdoblje stabilizacije ili imenovanu verziju, u posljednji trenutak odsijecate kratkotrajnu granu za izdanje s debla, stabilizirate je, objavite i izbrišete. Ispravci grešaka na objavljenoj verziji cherry-pickaju se natrag na deblo ili spajaju naprijed čim je to moguće. Kompromis je u tome što model zahtijeva testnu pokrivenost i zrelost CI-ja; tim bez automatiziranih testova jednostavno će cijeli dan rušiti deblo. Također zahtijeva da recenzija ostane brza, zbog čega DORA tešku, asinkronu recenziju koda navodi kao čestu zamku.

Grane za značajke i GitHub Flow

GitHub Flow najjednostavniji je model temeljen na granama koji svakoj promjeni i dalje daje točku recenzije. Mehanika je petlja: stvorite granu iz maina, napravite fokusiranu promjenu, otvorite zahtjev za spajanje, pokrenite provjere, dobijete odobravajuću recenziju, spojite i izbrišete granu. main ostaje u svakom trenutku objavljiv, a objava je prirodna posljedica spajanja.

Prakse koje ga čine funkcionalnim iste su one koje čine funkcionalnim svaki tok, primijenjene na jednu granu:

Kratki, opisni nazivi grana poput fix-checkout-timeout ili add-sitemap. Naziv je obećanje o opsegu.
Izolirani, cjeloviti commitovi. Svaki bi commit trebao biti jedna promjena koju možete samostalno vratiti. Preimenovanje varijable i njezini testovi pripadaju u odvojene commitove.
Nacrtni zahtjevi za spajanje (draft) za ranu povratnu informaciju, prije nego rad bude dovršen.
Brisanje grane nakon spajanja. GitHub zadržava zahtjev i njegovu povijest, pa se ništa ne gubi.

GitHub Flow pretpostavlja da isporučujete kontinuirano i da je main uvijek objavljiv, a raspada se kada grane prestanu biti kratkotrajne. Grana za značajku koja živi tri tjedna skrivena je develop grana bez ikakve strukture Git Flowa oko nje. Timovi koji dnevno spajaju mnogo malih zahtjeva nailaze na drugi problem: dok provjere zahtjeva završe, main se pomaknuo i zeleni je rezultat zastario. Standardni je odgovor red čekanja spajanja, koji grupira zahtjeve, ponovno pokreće provjere prema najnovijem mainu i spaja samo ono što je i dalje zeleno. GitHub to dokumentira kao način da zauzeta zaštićena grana ostane neoštećena dok automatizacija preuzima spajanje.

Grane za izdanja u stilu GitLab Flowa

GitLab Flow zadržava jedan main za produkciju i dodaje grane samo kada stvarnost to zahtijeva. Dvije su varijante ovdje važne.

Prva su grane za okruženja: pre-production, production ili slično, koje predstavljaju faze objave. Rad na značajkama spaja se na main; izdanja napreduju kroz grane okruženja, pa uvijek točno znate što se vrti gdje. To odgovara timovima s faznim objavama i revizijskim zahtjevima — možete s povjerenjem reći koji je kod u stagingu, a koji u produkciji.

Druga su verzionirane grane za izdanja, koje se koriste kada proizvod mora isporučivati imenovane verzije ili podržavati nekoliko verzija odjednom. Grana trenutačne verzije prima značajke i hitne ispravke; naslijeđene grane primaju samo hitne ispravke i sigurnosna izdanja. GitLabova dokumentacija eksplicitno navodi kritično pravilo: ako držite dugovječne grane za izdanja, morate definirati i provoditi proces hitnih ispravaka. “Ako nije definiran i proveden, svaka promjena postaje hitni ispravak.” Bez te discipline grana za izdanje postaje drugi main i vraćate se u kaos dviju grana s dodatnim koracima.

Kompromis je razmjeran broju verzija koje podržavate. Svaka podržana verzija množi posao spajanja: ispravci moraju ići na deblo i na svaku pogođenu granu izdanja. Sam GitLab savjetuje izbjegavanje dugovječnih grana osim ako nemate ugovorne obveze te preferiranje prekidača značajki nad granama kada je cilj samo držati neobjavljeni rad odvojenim. Ovaj je model pravi izbor za biblioteke, mobilne aplikacije s ciklusima recenzije u trgovinama i proizvode s ugovorima koji fiksiraju određene verzije.

Procesi u stilu Git Flowa

Potpuni proces Git Flowa dvogranasti je model s njegovom pomoćnom postavom: grane za značajke nastaju iz developa i spajaju se natrag u njega; grana za izdanje odsijeca se od developa, stabilizira te spaja u main i develop uz verzijski tag; grana za hitni ispravak odsijeca se od maina, popravlja, tagira te spaja u main i develop (ili u trenutačnu granu izdanja). Riječ je o cjelovitom, samodosljednom stroju za zakazana, verzionirana izdanja.

Model i dalje opravdava svoje postojanje u uskom pojasu situacija: proizvodi koji isporučuju imenovane verzije po fiksnom rasporedu, timovi koji moraju podržavati više objavljenih verzija i okruženja u kojima usklađenost želi vidljiv zapis onoga što je ušlo u svako izdanje. Driessenov osvrt iz 2020. pošten je sažetak — za eksplicitno verzionirani softver s više verzija u divljini model i dalje može dobro pristajati.

Troškovi su stvarni. develop je trajna integracijska grana koja odluta i od stvarnosti i od maina. Svako izdanje zahtijeva spajanje grane izdanja natrag u develop, a svaki se hitni ispravak mora spojiti dvaput — u main i u develop. Vlakovi izdanja znače da gotov rad čeka na sljedeći vlak, što produljuje vrijeme do isporuke, a integracija s CI/CD-om nezgrapna je: s dvije dugovječne grane, što uopće znači “build” i koja grana objavljuje? Timovi koji biraju Git Flow trebali bi to učiniti jer isporučuju verzije po rasporedu, a ne zato što je to model koji su svi prvi naučili.

Prekidači značajki: sloj koji mijenja kompromis

Prekidači značajki — također zvani feature flagovi — odvajaju objavu od izdanja. Kod šaljete u produkciju dok ostaje nevidljiv iza prekidača, a prekidač uključite kada je značajka spremna. Prekidač ne mijenja vaš model grananja; mijenja količinu grananja koja vam treba. Velike promjene koje traju više tjedana i inače bi zahtijevale dugovječnu granu mogu živjeti na deblu iza prekidača, kontinuirano integrirane i testirane, a korisnicima se izlažu kada su stvarno dovršene.

Fowlerov članak o prekidačima značajki kanonska je referenca i vrijedi ga pročitati u cijelosti. Nekoliko razlika praktično je važno:

Prekidači izdanja skrivaju nedovršeni rad u produkciji i uklanjaju se kada značajka zaživi.
Prekidači eksperimenata podržavaju A/B testiranje i mogu biti dugovječni.
Operativni prekidači jesu prekidači za upravljanje, poput prekidača koji tijekom incidenta isključuje skupi dio koda.
Prekidači dozvola otvaraju značajke određenim korisnicima ili grupama, korisno za postupno uvođenje.

Isti mehanizam omogućuje canary objave — izlaganje značajke malom postotku korisnika, praćenje metrika i zatim širenje — te daje brz put povratka bez vraćanja koda.

Cijena je u tome što su prekidači zaliha. Svaki dodaje uvjetnu logiku i teret testiranja, a brzo se množe. Fowler savjetuje da prekidače tretirate kao zalihe koje nose trošak držanja: kada stvorite prekidač izdanja, dodajte zadatak uklanjanja u backlog, stavite prekidačima datume isteka i ograničite koliko ih sustav smije sadržavati. Poučna je priča Knight Capital, čiji incident iz 2012. — pogrešno objavljen prekidač u kombinaciji s neispitanim prekidačem za isključenje — proizveo gubitak od 460 milijuna dolara. Prekidači su moćni i zbog te moći upravo i zahtijevaju higijenu.

Zahtjevi za spajanje napravljeni dobro

Zahtjevi za spajanje mehanizam su recenzije, a ne radni tok. Kada se koriste dobro, hvataju greške, šire znanje i daju timu zapis o tome zašto se promjena dogodila. Kada se koriste loše, postaju usko grlo u kojem rad danima čeka.

Prakse koje održavaju zahtjeve zdravima:

Držite ih malima. Jedna briga po zahtjevu. Recenzent može usvojiti diff od 200 redaka; diff od 2.000 redaka preleti se pogledom, a upravo se tamo skrivaju greške.
Napišite opis za recenzenta. Što se promijenilo, zašto, što ste testirali, što niste i kako to provjeriti. Povežite problem koji promjena rješava.
Recenzirajte odmah. DORA-ini podaci povezuju sporu recenziju s gomilanjem: kada recenzija traje danima, programeri prestaju raditi male promjene i počinju slagati veće. Recenzija tuđe promjene u roku od nekoliko sati timska je obveza, a ne usluga.
Koristite nacrte za ranu povratnu informaciju. Otvorite nacrtni zahtjev prije nego implementacija bude dovršena i postavite ciljana pitanja.
Za timove na deblu recenziju tretirajte kao sinkronu. Programiranje u paru ili trenutačna recenzija u trenutku commita drži kašnjenje spajanja blizu nule.

Zahtjevi nisu besplatni. Pojedinačni programer ili dvoje ljudi često ne dobivaju ništa od ceremonije, a hitni ispravak ne bi trebao čekati rundu recenzije kada je promjena jednoredni povratak. Postavke zaštite opisane u nastavku daju fleksibilnost da recenziju zahtijevate samo tamo gdje se isplati.

Provjere CI-ja koje pripadaju u vrata spajanja

Provjere koje zahtijevate prije spajanja definiraju što “zeleno” znači za vaše spremište. Razumna osnovica za većinu projekata: lintanje, provjera tipova, jedinični testovi, produkcijski build i pregledna objava za sve što mijenja korisnički vidljiv izlaz. Integracijski testovi pripadaju u vrata čim postanu brzi i stabilni. GitHubova dokumentacija bilježi jednu praktičnu zamku: nazivi poslova moraju biti jedinstveni unutar svih tokova rada, inače dvosmislene provjere statusa mogu blokirati spajanje bez jasnog razloga.

Dva svojstva odlučuju pomažu li provjere ili odmažu. Brzina — build od četrdeset minuta uči ljude gomilati promjene i spajati optimistično; build od pet minuta čini vrata jeftinima. Pouzdanost — nestabilan test uči ljude klikati “ponovi” i prestati vjerovati rezultatu, što vrata čini beskorisnima. Nestabilne testove popravljajte kao greške u produkciji.

Pravilo koje sve povezuje jest zeleni main: prvi je posao tima pri kvarnom CI-ju vratiti ispravno stanje — popravite naprijed ako je popravak brz, vratite ako nije. To je disciplina koja razvoj na deblu i GitHub Flow čini sigurnima i koju zaštita grana provodi mehanički.

Zaštita grana

Zaštita grana mehanizam je koji bilo koji od ovih radnih tokova pretvara iz prijedloga u provedeni proces. Na GitHubu pravilo zaštite na mainu može zahtijevati odobravajuće recenzije zahtjeva, prolazak provjera statusa, blokiranje force pusha, blokiranje brisanja, linearnu povijest commitova i potpisane commitove. GitLab nudi istu stvar sa zaštićenim granama i obveznim odobrenjima zahtjeva za spajanje.

Postavke koje su u praksi najvažnije:

Obvezne provjere statusa. Ništa se ne spaja dok CI nije zelen.
Obvezne recenzije. Barem jedno odobrenje osobe s pravom pisanja. Odbacite zastarjela odobrenja kako bi se promijenjeni diff recenzirao ponovno.
Blokiranje force pusha. Zaštitite zajedničku povijest na mainu od prepisivanja. Force push pripada kratkotrajnim osobnim granama, a ne deblu.
Linearna povijest ako vaš tim preferira plosnat, čitljiv git log.
Potpisani commitovi tamo gdje integritet opskrbnog lanca ili usklađenost to zahtijeva.
Red čekanja spajanja za zauzeta spremišta: red grupira zahtjeve, pokreće provjere prema najnovijem mainu i spaja samo one koji i dalje prolaze. Uklanja utrku u kojoj se main pomakne između vaše zelene provjere i klika na spajanje.

I zaštita ima cijenu. Pretjerana zaštita — tri odobrenja za svaku promjenu — upravo je težak proces recenzije koji DORA identificira kao zamku razvoja na deblu. Počnite s minimumom koji timu daje sigurnost: obvezne provjere, jedno odobrenje, bez force pusha. Ograničenja dodajte tek kada vas na to natjera konkretan kvar.

Objava i hitni ispravci

Izdanja su mjesto gdje radni tokovi prestaju biti teoretski. Ako objavljujete kontinuirano, objava je tag: main je uvijek objavljiv, a objava koja slijedi nakon spajanja rutinska je. Ako isporučujete imenovane verzije, trebate odluku o tome što grana izdanja sadrži i tko je smije mijenjati.

Hitni ispravak najrizičnija je promjena koju većina timova radi, jer dira produkciju pod pritiskom. Uzorak koji preživljava dodir sa stvarnošću:

Granajte od taga izdanja ili maina — nikada od stare grane za značajku.
Napravite najmanji mogući popravak, uz test regresije.
Pokrenite cijela vrata CI-ja, ne samo jedan test.
Objavite i provjerite.
Spojite popravak natrag na deblo i na svaku podržanu granu izdanja ili ga cherry-pickajte gdje je spajanje nepraktično.
Označite novu verziju. SemVer je korisna konvencija: hitni ispravak podiže broj zakrpe.

Povratak naspram popravka naprijed zaslužuje eksplicitnu odluku. Ako je popravak brz i dobro razumljiv, objavite ga. Ako bi popravak trajao satima, a povratak minutama — i povratak ne gubi podatke niti zahtijeva migraciju — prvo vratite, pa mirno popravljajte. Oba su legitimna; pogreška je improvizirati pod pritiskom umjesto imati zadani postupak.

Kratkotrajne grane i čitljiva povijest

Trajanje grane najbolji je pojedinačni pokazatelj toga koliko će vaša spajanja biti bolna. Grane na deblu trebale bi živjeti satima; grane za značajke danima, rijetko tjednima. Grana koja živi dulje od tjedan dana znak je da rad nije dovoljno podijeljen, da je recenzija prespora ili da je promjena prevelika da bi uopće bila grana — možda joj treba prekidač značajke.

Čitljiva povijest dar je koji ostavljate osobi koja u 2 ujutro traži grešku, a to ste obično vi. Prakse su jednostavne:

Atomski commitovi. Jedna logična promjena po commitou, zajedno sa svojim testovima.
Opisne poruke. Recite što i zašto, ne kako. “Popravi timeout naplate za velike košarice” bolje je od “update”.
Svjesno birajte strategiju spajanja. Spojni commitovi čuvaju topologiju grana i grupiraju commitove značajke; squash daje čistu linearnu povijest, ali gubi međukorake; rebase linearizira povijest po cijenu njezina prepisivanja. Točan odgovor ovisi o vašem timu, a GitHubova zaštita “require linear history” čini izbor eksplicitnim i dosljednim.
Nikada ne prepisujte zajedničku povijest. Force pushajte samo grane na kojima radite sami. Prepisivanje maina ili zajedničke grane izdanja način je na koji kolege izgube rad.

Okvir odlučivanja za izbor radnog toka

Ne postoji univerzalno ispravan radni tok, ali odluka nije bacanje novčića. Odgovorite na četiri pitanja i karta u nastavku pokriva većinu timova.

Koliko često možete objavljivati? Dnevno ili češće — preferirajte razvoj temeljen na deblu ili GitHub Flow. Tjedno ili po rasporedu — grane za izdanja ili Git Flow počinju opravdavati postojanje. Ciklusi recenzije u trgovinama ili verzije fiksirane ugovorom — verzionirane grane za izdanja.
Morate li podržavati više objavljenih verzija? Jedna trenutačna verzija — držite stvari jednostavnima. Trenutačna plus naslijeđene — dugovječne grane za izdanja sa strogim, provedenim procesom hitnih ispravaka.
Koliko je velik tim? Jedna ili dvije osobe — razvoj na deblu s izravnim commitovima na zaštićeni main i zahtjevima za spajanje samo za promjene koje želite recenzirati. Pet do dvadeset ljudi — GitHub Flow ili GitLab Flow sa zaštićenim mainom i redom čekanja spajanja ako su spajanja česta. Veći ili regulirani — dodajte strukturu promišljeno, grane okruženja ili cijeli proces izdanja, samo tamo gdje to zahtijevaju usklađenost ili koordinacija.
Koliko košta loše izdanje? Malo — možete si priuštiti najjednostavniji tok i brzu objavu. Puno — uložite u provjere, fazne objave i uvježban put povratka prije nego što uložite u više grana.

Poštena preporuka za većinu timova koji kreću: GitHub Flow (ili razvoj temeljen na deblu) na zaštićenom mainu, mali zahtjevi za spajanje, brz CI i grane za izdanja tek kada stvarno objavljujete iz tagova. Strukturu u stilu Git Flowa dodajte samo ako isporučujete imenovane verzije po rasporedu i trebate zapis izdanja. Prekidače značajki dodajte u trenutku kada osjetite poriv da za rad u tijeku stvorite dugovječnu granu. Pregledajte odluku kada se promijene veličina tima, učestalost objava ili profil rizika — radni tok koji je odgovarao startupu od tri osobe rijetko odgovara istom proizvodu s dvadeset ljudi.

Česte pogreške

Dugovječne grane za značajke. Grana od tri tjedna druga je develop grana bez discipline. Podijelite rad ili upotrijebite prekidač.
Zaštićeni main bez pravog CI-ja. Zahtijevanje provjera koje su nestabilne, spore ili nepotpune daje lažno povjerenje.
Red čekanja spajanja prišrafljen na spore provjere. Red pomaže samo kada je osnovni build dovoljno brz da prati količinu spajanja.
Prekidači značajki koji se nikada ne uklanjaju. Svaki je prekidač zaliha; zakažite njegovo uklanjanje kada ga stvorite.
Hitni ispravci koji preskaču recenziju i nikada se ne spoje natrag. Popravak stigne u produkciju i nestane s debla, pa se greška vraća u sljedećem izdanju.
Prepisivanje zajedničke povijesti. Force push na main ili granu izdanja uništava rad kolega i vaš revizijski trag.
Zamrzavanje koda kao strategija izdanja. Zamrzavanje je simptom rijetkih i velikih spajanja; rješenje su manje serije i kraće grane.
Biranje radnog toka po modi. Git Flow nije automatski pogrešan, a razvoj temeljen na deblu nije automatski ispravan. Oba su alati s kontekstom.

Pošteni sažetak

Okvir main-vs-develop postavljao je pogrešno pitanje. Prave su varijable trajanje grana, veličina serije, ritam objava i rizik — a radni tok koji odaberete samo je mehanizam za upravljanje njima. Razvoj temeljen na deblu i GitHub Flow minimiziraju trajanje grana i veličinu serije, a plaćaju to disciplinom CI-ja i testiranja. Grane za izdanja i procesi u stilu Git Flowa mijenjaju jednostavnost za kontrolu nad verzioniranim, zakazanim izdanjima. Prekidači značajki smanjuju količinu grananja koja vam uopće treba.

Počnite jednostavnije nego što mislite da trebate. Zaštitite main, držite provjere smislenima, držite grane kratkima i dodajte strukturu tek kada je proizvod, tim ili regulatori stvarno zahtijevaju. Zatim ponovno preispitajte izbor kako se ta ograničenja mijenjaju — to je radni tok koji funkcionira.

Izvori: GitHub Flow, GitHub: O zaštićenim granama, GitHub: Upravljanje redom čekanja spajanja, GitLab: Strategije grananja, DORA: Razvoj temeljen na deblu, Martin Fowler: Prekidači značajki, Trunk Based Development, Atlassian: Gitflow radni tok, Vincent Driessen: A successful Git branching model.