Sedaj, ko imate osnove vej in združevanja, kaj z njimi lahko ali bi z njimi morali narediti? V tem razdelku bomo pokrili nekaj pogostih potekov dela, kar ta lahkotna razvejanja omogočijo, da se lahko odločite, ali bi jih želeli vkomponirati v vaš lastni razvojni cikel.
Ker Git uporablja enostavno tri-načinsko združevanje, je združevanje iz ene veje v drugo večkrat skozi daljše časovno obdobje v splošnem enostavno. To pomeni, da imate nekaj vej, ki so vedno odprte in jih uporabljate za različne faze svojega razvojnega cikla; pogostokrat lahko združite iz nekaj njih v druge.
Mnogi Git razvijalci imajo potek dela, ki zajema tak pristop, kot je imeti samo kodo, ki je v celoti stabilna v njihovi veji master
— verjetno samo koda, ki je bila ali pa bo izdana.
Imajo drugo vzporedno vejo imenovano develop
ali next
, iz katere delajo ali pa jo uporabljajo za testiranje stabilnosti — ni nujno vedno stabilna, vendar kadarkoli doseže stabilno stanje, se jo lahko združi v master
.
Uporabljena je za poteg tematskih vej (kratkotrajne veje, kot je vaša prejšnja veja iss53
), ko so pripravljene, da se zagotovi, da prestanejo vse teste in ne povzročajo napak.
V resnici govorimo o kazalcih, ki se premikajo navzgor po poti potrjevanj, ki jih delate. Stabilne veje so nižje na poti v vaši zgodovini potrditev in najnovejše veje so bolj na vrhu zgodovine.
V splošnem je o njih enostavnejše razmišljati kot o delovnih silosih, kjer skupki potrditev napredujejo k bolj stabilnim silosom, ko so v celoti testirani.
Tako delo lahko nadaljujete na mnogih nivojih stabilnosti.
Nekateri večji projekti imajo tudi vejo proposed
ali pu
(angl. proposed updates), ki ima integrirane veje, ki še niso pripravljene, da grejo v vejo next
ali master
.
Ideja je, da so vaše veje na različnih nivojih stabilnosti; ko dosežejo stabilnejši nivo, so združene v vejo nad njimi.
Ni treba imeti več dolgotrajnih vej, vendar je to pogostokrat koristno, posebej ko imate opravka z zelo velikimi in kompleksnimi projekti.
Tematske veje na drugi strani so uporabne v projektih kakršnihkoli velikosti. Tematska veja je kratkotrajna veja, ki ste jo izdelali in jo uporabljate za posamezno določeno lastnost ali povezano delo. To je nekaj, česar verjetno še nikoli niste počeli z VCS prej, ker je v splošnem predrago izdelovati in združevati veje. Vendar v Gitu je pogosto izdelati, delati na, združiti in izbrisati veje nekajkrat na dan.
To ste videli v zadnjem razdelku pri ustvarjanju vej iss53
in hotfix
.
Na njih ste naredili nekaj potrditev in jih takoj izbrisali po združitvi v glavno vejo.
Ta tehnika vam omogoča kontekstni preklop hitro in v celoti — ker je vaše delo razdeljeno v nekaj silosov, kjer morajo biti vse spremembe v tej veji povezane z določeno temo, je enostavnejše videti, kaj se je zgodilo med pregledom kode in podobno.
Tam lahko sledite spremembam nekaj minut, dni, ali mesecev in jih združite, ko ste pripravljeni ne glede na vrstni red, v katerem ste jih ustvarili ali delali na njih.
Premislite o primeru, ko delate na nekem delu (na master
), razvejate za težavo (iss91
), delate ne njej nekaj časa, razvejate drugo vejo, da poskusite drug način upravljanja z isto stvarjo (iss91v2
), se vrnete na vašo vejo master
in delate tam nekaj časa in nato razvejate, da naredite nekaj dela, za katero niste prepričani, če je dobra ideja (veja dumbidea
).
Vaša zgodovina potrditev bo videti nekako takole:
Sedaj recimo, da se odločite, da imate raje drugo rešitev za svojo težavo (iss91v2
); svojim sodelavcem ste pokazali vejo dumbidea
in izkaže se, da je genialna.
Originalno vejo iss91
lahko vržete stran (izgubite potrditvi C5
in C6
) in jo združite v drugi dve.
Vaša zgodovina je potem videti takole:
V večje podrobnosti o različnih možnih potekih dela za vaš Git projekt bomo šli v poglavju ch05-distributed-git.asc, tako da preden se odločite, katero shemo razvejanja bo vaš naslednji projekt uporabljal, se prepričajte, da ste prebrali to poglavje.
Pomembno si je zapomniti, da ko delate vse to, so te veje v celoti lokalne. Ko razvejujete in združujete, je vse narejeno samo v vašem repozitoriju Git — ne dogaja se nikakršna komunikacija s strežnikom.