Za razvoj kakovostne programske opreme moramo biti sposobni slediti vsem spremembam in jih po potrebi obrniti. Sistemi za nadzor različic izpolnjujejo to vlogo tako, da sledijo zgodovini projektov in pomagajo združiti spremembe več ljudi. Zelo pospešijo delo in nam omogočijo lažje iskanje napak.

Poleg tega je delo v porazdeljenih skupinah mogoče predvsem s pomočjo teh orodij. Omogočajo več ljudem, da hkrati delajo na različnih delih projekta in kasneje svoje rezultate združijo v en izdelek. Oglejmo si podrobneje sisteme za nadzor različic in razložimo, kako sta nastala razvoj na osnovi trunk in Git flow.

Kako so sistemi za nadzor različic spremenili svet

Preden so bili ustvarjeni sistemi za nadzor različic, so se ljudje zanašali na ročno varnostno kopiranje prejšnjih različic projektov. Ročno so kopirali spremenjene datoteke, da bi vključili delo več razvijalcev na istem projektu.

To je stalo veliko časa, prostora na trdem disku in denarja.

Ko smo poglejte zgodovino , na splošno lahko ločimo tri generacije programske opreme za nadzor različic.

Oglejmo si jih:

Generacija	Operacije	Sočasnost	Mreženje	Primeri
Najprej	Samo v eni datoteki	Ključavnice	Centralizirano	RCS
Drugič	Na več datotekah	Spoji pred objavo	Centralizirano	Subverzija, CVS
Tretjič	Na več datotekah	Objavi pred združitvijo	Porazdeljeno	Git, Mercurial

Opažamo, da s staranjem sistemov za nadzor različic obstaja težnja po povečanju zmožnosti vzporednega dela na projektih.

Ena najbolj prelomnih sprememb je bil prehod z zaklepanja datotek na združevanje sprememb. Programerjem je omogočil učinkovitejše delo.

Drugi pomemben napredek je bila uvedba porazdeljenih sistemov. Git je bil eden prvih orodja za vključitev te filozofije. Dobesedno je omogočil razcvet odprtokodnega sveta. Git razvijalcem omogoča kopiranje celotnega repozitorija v operaciji, imenovani forking, in uvedbo želenih sprememb, ne da bi morali skrbeti za konflikte spajanja.

Kasneje lahko sprožijo zahtevo za vlečenje, da svoje spremembe združijo v prvotni projekt. Če začetni razvijalec ne želi vključiti teh sprememb iz drugih skladišč, jih lahko sam spremeni v ločene projekte. Vse je mogoče zahvaljujoč dejstvu, da ne obstaja koncept centralnega shranjevanja.

Slogi razvoja

Dandanes je najbolj priljubljen sistem za nadzor različic Git s tržnim deležem v letu 2016 približno 70 odstotkov.

Git je bil populariziran z vzponom Linuxa in odprtokodne scene na splošno. GitHub , ki je trenutno najbolj priljubljeno spletno shrambo za javne projekte, je tudi znatno prispevalo k njegovi razširjenosti. Uvedbo zahtev za povlečenje zahtev za Git dolgujemo.

Poenostavljeno potegnjene zahteve so zahteve, ki jih je ustvaril razvijalec programske opreme za združitev sprememb, ki so jih ustvarili z glavnim projektom. Vključuje postopek pregleda teh sprememb. Ocenjevalci lahko vstavijo komentarje na vsak del, za katerega menijo, da bi ga bilo mogoče izboljšati, ali menijo, da je nepotreben.

Po prejemu povratnih informacij lahko ustvarjalec odgovori nanjo, ustvari razpravo ali pa ji preprosto sledi in ustrezno spremeni svojo kodo.

Git je zgolj orodje. Uporabite ga lahko na različne načine. Trenutno sta dva najbolj priljubljena razvojna stila, s katerimi se lahko srečate Git tok in razvoj na podlagi debla . Ljudje pogosto poznajo enega od teh stilov, drugega pa lahko zanemarijo.

Poglejmo si jih podrobneje oba in se naučite, kako in kdaj jih moramo uporabljati.

Git Flow

V razvojnem modelu Git flow imate eno glavno razvojno vejo s strogim dostopom do nje. Pogosto se imenuje develop podružnica.

Razvijalci iz te glavne veje ustvarijo značilne veje in delajo na njih. Ko končajo, ustvarijo zahteve za vlečenje. V zahtevah za vlečenje drugi razvijalci komentirajo spremembe in imajo lahko razprave, pogosto precej dolgotrajne.

Traja nekaj časa, da se dogovorimo o končni različici sprememb. Ko je dogovorjen, je zahteva za vlečenje sprejeta in združena z glavno vejo. Ko se odloči, da je glavna veja dosegla dovolj zrelosti, da jo je mogoče izdati, se ustvari ločena veja za pripravo končne različice. Aplikacija iz te veje je preizkušena in popravki napak so uporabljeni do trenutka, ko je pripravljena za objavo končnim uporabnikom. Ko je to končano, združimo končni izdelek z master in jo označite z različico za izdajo. Medtem lahko na develop razvijemo nove funkcije podružnica.

Spodaj si lahko ogledate diagram poteka Git, ki prikazuje splošni potek dela:

Ena od prednosti Git flow je strog nadzor. Samo pooblaščeni razvijalci lahko po natančnem pregledu odobrijo spremembe. Zagotavlja kakovost kode in pomaga pri zgodnjem odpravljanju napak.

Vendar se morate zavedati, da je to lahko tudi velika pomanjkljivost. Ustvari lijak, ki upočasni razvoj programske opreme. Če je hitrost vaša glavna skrb, potem je to lahko resen problem. Ločeno razvite funkcije lahko ustvarijo dolgožive veje, ki jih je težko združiti z glavnim projektom.

Še več, zahteve za vlečenje osredotočajo pregled kode samo na novo kodo. Namesto da bi gledali na kodo kot celoto in si prizadevali, da bi jo izboljšali kot tako, preverjajo le na novo uvedene spremembe. V nekaterih primerih lahko vodijo do prezgodnja optimizacija saj je vedno mogoče izvesti nekaj, kar bo hitreje izvedlo.

Poleg tega lahko zahteve za vlečenje vodijo do obsežnega mikro-upravljanja, kjer vodilni razvijalec dobesedno upravlja vsako posamezno vrstico kode. Če imate izkušene razvijalce, ki jim lahko zaupate, bodo oni to lahko rešili, vendar morda izgubljate njihov čas in spretnosti. Razvijalce lahko tudi močno motivira.

V večjih organizacijah je še ena skrb pisarniška politika med zahtevami za vleko. Mogoče je, da bi ljudje, ki odobrijo zahteve za vlečenje, lahko uporabili svoj položaj, da določenim razvijalcem namerno preprečijo kakršne koli spremembe osnove kode. To lahko storijo zaradi nezaupanja, nekateri pa lahko zlorabijo svoj položaj, da poravnajo osebne račune.

Prednosti in slabosti Git Flow

Kot lahko vidite, izvajanje zahtev za vlečenje morda ni vedno najboljša izbira. Uporabiti jih je treba le, če je to primerno.

Kdaj Git Flow deluje najbolje?

• Ko zaženete odprtokodni projekt.
  Ta slog prihaja iz odprtokodnega sveta in tam najbolje deluje. Ker lahko vsi prispevajo, želite imeti zelo strog dostop do vseh sprememb. Želite imeti možnost preveriti vsako posamezno vrstico kode, saj odkrito ne morete zaupati ljudem, ki prispevajo. Običajno to niso komercialni projekti, zato hitrost razvoja ne skrbi.

• Ko imate veliko mlajših razvijalcev.
  Če večinoma sodelujete z mlajšimi razvijalci, potem želite, da natančno preverite njihovo delo. Lahko jim daš več namigov, kako lahko stvari počnejo bolj učinkovito in jim pomagaš hitreje izboljšati svoje spretnosti. Ljudje, ki sprejemajo zahteve za vlečenje, imajo strog nadzor nad ponavljajočimi se spremembami, da lahko preprečijo poslabšanje kakovosti kode.

• Ko imate uveljavljen izdelek.
  Zdi se, da se ta slog dobro obnese tudi, če že imate uspešen izdelek. V takih primerih je navadno poudarek na zmogljivosti aplikacije in zmožnostih nalaganja. Takšna optimizacija zahteva zelo natančne spremembe. Običajno čas ni omejitev, zato ta slog tukaj dobro deluje. Še več, velika podjetja so zelo primerna za ta slog. Vsako spremembo morajo natančno nadzorovati, saj nočejo prekiniti večmilijonske naložbe.

Kdaj lahko Git Flow povzroči težave?

• Ko šele začenjate.
  Če šele začenjate, potem Git flow ni za vas. Verjetno želite hitro ustvariti minimalno izvedljiv izdelek. Zahteve za vlečenje ustvarjajo ogromno ozko grlo, ki dramatično upočasni celotno ekipo. Preprosto si tega ne morete privoščiti. Težava pri pretoku Git je v tem, da zahteve za vlečenje lahko vzamejo veliko časa. Preprosto ni mogoče zagotoviti hitrega razvoja na ta način.

• Ko morate hitro ponoviti.
  Ko pridete do prve različice izdelka, ga boste najverjetneje morali nekajkrat zavrteti, da boste zadovoljili potrebe svojih strank. Spet več zahtev za veje in vlečenje dramatično zmanjša hitrost razvoja in v takšnih primerih ni priporočljivo.

• Ko večinoma delate s starejšimi razvijalci.
  Če je vaša ekipa v glavnem starejših razvijalcev, ki so dlje časa delali med seboj, prej omenjenega mikroupravljanja z zahtevami za vlečenje v resnici ne potrebujete. Zaupate svojim razvijalcem in veste, da so profesionalci. Naj opravljajo svoje delo in jih ne upočasnjujte z vso birokracijo Git flow.

Razvojni delovni tok na osnovi trunk

V razvojnem modelu, ki temelji na deblu, vsi razvijalci delajo na eni veji z odprtim dostopom do nje. Pogosto je to preprosto master podružnica. Njim dodelijo kodo in jo zaženejo. Je zelo preprosto.

V nekaterih primerih ustvarijo kratkotrajne veje. Ko koda na njihovi veji zbere in opravi vse teste, jo združijo naravnost v master Zagotavlja, da je razvoj resnično neprekinjen, in razvijalcem preprečuje ustvarjanje sporov, ki jih je težko rešiti.

Oglejmo si razvojni potek na osnovi debla.

Edini način za pregled kode pri takem pristopu je popoln pregled izvorne kode. Ponavadi so dolgotrajne razprave omejene. Nihče nima strogega nadzora nad tem, kaj se spreminja v osnovi izvorne kode - zato je pomembno, da je vzpostavljen izvršljiv slog kode. Razvijalci, ki delajo v takem slogu, morajo biti izkušeni, da boste vedeli, da ne bodo znižali kakovosti izvorne kode.

Ta način dela je lahko odličen, če sodelujete z ekipo prekaljeni razvijalci programske opreme . Omogoča jim hitro in brez nepotrebne birokracije nove izboljšave. Pokaže jim tudi, da jim zaupate, saj lahko kodo vnesejo naravnost v master podružnica. Razvijalci v tem delovnem procesu so zelo samostojni - neposredno izvajajo in preverjajo končne rezultate v delujočem izdelku. Pri tej metodi je vsekakor veliko manj upravljanja z mikro in upravljanje pisarniške politike.

Če na drugi strani nimate začinjene ekipe ali jim iz nekega razloga ne zaupate, ne bi smeli slediti tej metodi - raje izberite Git flow. Rešili boste nepotrebnih skrbi.

Prednosti in slabosti razvoja na osnovi trunk

Oglejmo si podrobneje obe strani stroškov - najboljše in najslabše scenarije.

Kdaj razvoj na osnovi trunk deluje najbolje?

• Ko šele začenjate.
  Če delate na svojem najmanj izvedljivem izdelku, potem je ta slog kot nalašč za vas. Ponuja največjo hitrost razvoja z minimalno formalnostjo. Ker zahtev za vlečenje ni, lahko razvijalci s hitrostjo svetlobe dostavijo nove funkcije. Ne pozabite najeti izkušenih programerjev.

• Ko morate hitro ponoviti.
  Ko ste prišli do prve različice izdelka in ste opazili, da si stranke želijo nekaj drugačnega, potem ne premislite in s tem slogom zavrtite v novo smer. Še vedno ste v fazi raziskovanja in svoj izdelek morate čim hitreje spremeniti.

• Ko večinoma delate s starejšimi razvijalci.
  Če je vaša ekipa v glavnem starejših razvijalcev, jim zaupajte in jim dovolite, da opravljajo svoje delo. Ta potek dela jim daje samostojnost, ki jo potrebujejo, in jim omogoča, da obvladajo svoj poklic. Samo dajte jim namen (naloge, ki jih je treba opraviti) in opazujte, kako raste vaš izdelek.

Kdaj lahko razvoj, ki temelji na omrežju, povzroči težave?

• Ko zaženete odprtokodni projekt.
  Če izvajate odprtokodni projekt, je Git flow boljša možnost. Potrebujete zelo strog nadzor nad spremembami in ne morete zaupati sodelavcem. Navsezadnje lahko prispeva vsak. Vključno s spletnimi trolli.

• Ko imate veliko mlajših razvijalcev.
  Če najamete večinoma mlajše razvijalce, je bolje, da natančno nadzirate, kaj počnejo. Stroge zahteve za vlečenje jim bodo pomagale izboljšati svoje sposobnosti in hitreje bodo odkrile morebitne napake.

• Ko ste ustanovili izdelek ali vodite velike ekipe.
  Če že imate uspešen izdelek ali vodite velike ekipe v velikem podjetju, je morda boljša ideja Git flow. Želite imeti strog nadzor nad dogajanjem z dobro uveljavljenim izdelkom, vrednim milijone dolarjev. Verjetno sta najpomembnejša zmogljivost aplikacije in zmožnosti nalaganja. Takšna optimizacija zahteva zelo natančne spremembe.

Za pravo opravilo uporabite pravo orodje

Kot sem že rekel, je Git le orodje. Kot vsako drugo orodje ga je treba uporabljati ustrezno.

Git flow upravlja vse spremembe s pomočjo zahtev za vlečenje. Zagotavlja strog nadzor dostopa do vseh sprememb. Odličen je za odprtokodne projekte, velika podjetja, podjetja z uveljavljenimi izdelki ali skupino neizkušenih mlajših razvijalcev. Lahko varno preverite, kaj se vnaša v izvorno kodo. Po drugi strani pa lahko vodi do obsežnega mikro-upravljanja, sporov, ki vključujejo pisarniško politiko, in bistveno počasnejšega razvoja.

Razvoj na osnovi trunk daje programerjem popolno avtonomijo in izraža več zaupanja vanje in njihovo presojo. Dostop do izvorne kode je brezplačen, zato morate resnično zaupati svoji ekipi. Zagotavlja odlično hitrost razvoja programske opreme in zmanjšuje procese. Zaradi teh dejavnikov je popoln pri ustvarjanju novih izdelkov ali vrtenju obstoječe aplikacije v povsem novi smeri. Čudi se, če večinoma sodelujete z izkušenimi razvijalci.

Kljub temu, če delate z mlajšimi programerji ali ljudmi, ki jim ne zaupate popolnoma, je Git flow veliko boljša alternativa.

Upam, da boste lahko s tem znanjem izbrali potek dela, ki se popolnoma ujema z vašim projektom.

Sorodno: Pojasnjen izboljšan Git Flow

Razumevanje osnov

Kaj je trunk v programski opremi?

V svetu razvoja programske opreme 'trunk' pomeni glavno razvojno vejo pod sistemom za nadzor različic. To je osnova projekta, kjer se vse izboljšave združujejo.

Kaj je razvejanje in združevanje kode?

Podružnice se ustvarijo iz osnovnega projekta, da bi razvili novo funkcijo, odpravili napako ali preprosto refaktorizirali. Razvijalcem programske opreme preprečujejo, da bi drug drugega motili in jim omogočajo vzporedno delo. Ko je sprememba končana in preizkušena, se veja združi nazaj v deblo.

Kaj je veja pri nadzoru različic?

Podružnica v sistemu za nadzor različic je dvojnik osnovnega projekta. Ustvarjen je tako, da se lahko spremembe dogajajo vzporedno v drugih vejah. V bistvu rešuje problem dela na istih datotekah hkrati.

Kaj je veja lastnosti?

Podružnica funkcije ima jasen in zelo osredotočen namen - projektu dodati posebno funkcionalnost. Ne sme vsebovati nobenih drugih sprememb, ki odpravljajo napake, uvajajo druge funkcije ali so del predelave.

Kaj je sistem za nadzor različic?

Sistemi za nadzor različic sledijo spremembam, ki se pojavijo v datotekah v projektu. Kasneje jih je mogoče priklicati ali pregledati. Izredno koristen je tudi za vrnitev prejšnjih različic. To razvijalcem omogoča iskanje napak z manj truda, saj lahko vidijo in spremljajo vse spremembe, kot so se zgodile.