Mis on Git ja miks peaksite kasutama versioonikontrolli, kui olete arendaja

Reklaam

Veebiarendajatena kipume enamasti töötama kohalikel arendussaitidel, siis laadige lihtsalt kõik üles, kui oleme valmis. See on hästi, kui tegemist on ainult teiega ja muudatused on väikesed, kuid kui tegelete mitmega inimene, kes töötab millegi kallal või suure projekti juures, kus on palju keerulisi komponente, see lihtsalt pole teostatav. Siis jõuame nn versioonikontrolli juurde.

Täna räägin ma avatud lähtekoodiga versioonikontrolli tarkvarast nimega Git. See võimaldab rohkem kui ühel inimesel sama projekti nimel turvaliselt töötada, üksteist segamata, kuid see on ka palju muud.

Miks kasutada versioonikontrolli tarkvara?

Esiteks peaks nimi selle ära andma. Versioonikontrolli tarkvara võimaldab teil omada projekti „versioone”, mis näitavad koodis aja jooksul tehtud muudatusi ning võimaldab vajadusel tagasi minna ja need muudatused tagasi võtta. Ainuüksi see võimalus - kui suudetakse võrrelda kahte versiooni või muuta muudatusi - muudab selle suuremate projektide kallal üsna hindamatuks.

Tõenäoliselt olete seda isegi mingil hetkel ise teinud, salvestades projekti koopiad erinevatest punktidest, et teil oleks varukoopia. Versioonikontrollisüsteemis salvestataks lihtsalt muudatused - paastifail, mida saaks rakendada ühele versioonile, et muuta see samaks järgmise versiooniga. Ühe arendajaga on see piisav.

Aga mis siis, kui teil on projekti kallal mitu arendajat? Siis saabub idee tsentraliseeritud versioonikontrolliserveri loomiseks. Need on olnud pikka aega standardiks, mille kohaselt kõik versioonid salvestatakse keskserverisse ning üksikud arendajad kontrollivad ja laadivad muudatused tagasi sellesse serverisse. Kui olete kunagi vaadanud Vikipeedia lehe redigeerimise ajalugu, on teil hea ettekujutus selle toimimisest pärismaailmas:

Sellise süsteemi eelisteks on see, et mitu arendajat saavad muudatusi teha ja iga muudatuse saab omistada konkreetsele arendajale. Negatiivne külg on see, et kõik on salvestatud kaugandmebaasi, see tähendab, et serveri alla minnes ei saa muudatusi teha; ja kui keskandmebaas kaob, on igal kliendil ainult praegune versioon sellest, millega nad töötasid.

See viib meid edasi Gitile ja muudele nn hajutatud versioonikontrollisüsteemid. Nendes süsteemides ei kontrolli kliendid lihtsalt failide praegust versiooni ega tööta neist välja - nad kajastavad kogu versiooniajalugu. Igal arendajal on alati kõigest täielik koopia. Keskserverit kasutatakse endiselt, kuid kui halvim juhtub, saab kõike siiski taastada igalt kliendilt, kellel on uusimad versioonid.

Git töötab spetsiaalselt failide hetktõmmiste tegemise teel; kui failid jäävad teatud versioonis muutumatuks, lingi lihtsalt eelmistele failidele - see hoiab kõik kiire ja lahja.

Samuti võiks teile huvi pakkuda, et Gitit kasutatakse veebisaidi haldamiseks ja arendamiseks tuum linux kernel - alus, millele kõik linux-distrod on üles ehitatud.

Mis on Github?

Ehkki saate oma Git-serverit lokaalselt käitada, Github on nii kaugserver, arendajate kogukond kui ka graafiline veebiliides teie Giti projekti haldamiseks. Seda saab tasuta kasutada kuni viies avalikus andmehoidlas - st kui keegi saab teie koodi vaadata või seda otsida - eraprojektide odavate plaanidega. Soovitan tungivalt registreeruda tasuta konto saamiseks, et saaksite hakata oma projektidega ringi mängima või kellegi käest nõutuks saama.

Kaarutamine ja hargnemine

Need on Giti kogemuse peamised kontseptsioonid, nii et võtame natuke aega erinevuse selgitamiseks.

Tõenäoliselt olete linuxi distrodega tegeledes kuulnud teost “kahvel”. Kui olete meediumikeskuse rakendusega Plex tuttav, siis teate, et see oli algselt sarnase avatud lähtekoodiga kahvel Xboxi meediumikeskus Aeon Nox 3.5: ilus ja kohandatav teema XBMC jaoksSeadke oma meediumikeskus täpselt nii, nagu soovite. Aeon Nox 3.5 on uusim versioon sellest, mis on võib-olla parim teema XBMC jaoks, ja see on haruldane kombinatsioon: ilus ... Loe rohkem . See tähendab lihtsalt, et mingil hetkel minevikus võtsid mõned arendajad XBMC koodi ja otsustasid minna sellega oma teed; sellest sai Plex.

See on muidugi täiesti lubatud, kui projekt on avatud lähtekoodiga - võite võtta koodi, teha sellega kõike, mida soovite. Giti puhul, kui tunnete, et teie muudatused on piisavalt head, et teid tagasi projekti “kapten” tagasi tõmmata, olete teie saab autorile esitada tõmbetaotluse, paludes neil tõmmata teie muudatused tagasi nende originaali projekti. See võimaldab teil igal hetkel projekti kallal töötada sadu tuhandeid arendajaid, kellest ükski ei tohi Koodile ligipääs peab olema kindlasti heaks kiidetud - nad lihtsalt kopeerivad koodi, teevad muudatusi ja taotlevad, et see saaks uuesti koodi sisestada peremees. Muidugi on algse projekti omaniku otsustada, kas nad otsustavad teie muudatustega nõustuda või mitte.

Hargnemine on volitatud arendajate tehtud projektisisene tegevus. See võimaldab teil konkreetseid probleeme või funktsioone hõlpsalt eraldada ja nendega töötada ilma põhifaile lõhkumata. Kui olete veendunud, et teie haru on selle probleemiga tegelenud, ühendate selle uuesti meistriks. Filiaale võib igal ajal olla nii palju kui soovite; nad ei sega üksteist. Samuti saate muudatusi harude vahel liita, ilma et peaksite pealikut puudutama.

Siit leiate suurepärase diagrammi töövoo näitest Vincent Driessen:

Järgmine kord uurime, kuidas seadistada toimiv Giti näide ja teha harudes koodimuudatusi. Versioonikontroll on tohutu teema. Olen siin vaid lühima ülevaate andnud, kuid arendajana, kes on harjunud lihtsalt muudatusi tegema ja nende tühistamise tühistama, kui need ei tööta, on kogu kontseptsioon mulle meelde tuletanud - loodan, et ka teie.

Kas olete kogenud arendaja, kellel on kogemusi Gitis? Kas olete alles alustanud ja arvate, et tahaksite käia? Kõlagu kommentaarides!