Programiranje

Vadnica za Git: Začnite z nadzorom različic Git

Ta članek vam predstavlja Git, vključno s tem, kako namestiti potrebno programsko opremo za dostop do strežnikov Git, kjer bo shranjen vaš projekt programske opreme.

Koncepti nadzora različic

Če želite razumeti Git in koncept nadzora različic, je koristen pogled na nadzor različic z zgodovinskega vidika. Obstajajo tri generacije programske opreme za nadzor različic.

Prva generacija

Prva generacija je bila zelo preprosta. Razvijalci so delali na istem fizičnem sistemu in "preverjali" po eno datoteko naenkrat.

Ta generacija programske opreme za nadzor različic je uporabila tehniko, imenovano zaklepanje datotek. Ko je razvijalec preveril datoteko, je bila zaklenjena, tako da je noben drug razvijalec ni mogel urediti.

Primeri programske opreme za nadzor različic prve generacije vključujejo sistem za nadzor revizij (RCS) in sistem za nadzor izvorne kode (SCCS).

Druga generacija

Težave s prvo generacijo so bile naslednje:

  • Datoteko je lahko hkrati delal le en razvijalec. To je povzročilo ozko grlo v razvojnem procesu.

  • Razvijalci so se morali prijaviti neposredno v sistem, ki je vseboval programsko opremo za nadzor različic.

Te težave so bile rešene v drugi generaciji programske opreme za nadzor različic. V drugi generaciji so datoteke shranjene na centraliziranem strežniku v repozitoriju. Razvijalci si lahko ogledajo ločene kopije datoteke. Ko razvijalec zaključi delo z datoteko, se datoteka prijavi v repozitorij.

Če dva razvijalca preverita isto različico datoteke, potem obstaja težava. To reši postopek, imenovan a združiti.

Kaj je združitev? Recimo, da dva razvijalca, Bob in Sue, preverita različico 5 datoteke z imenom abc.txt. Ko Bob konča svoje delo, datoteko znova preveri. Običajno to povzroči novo različico datoteke, različico 6.

Nekje kasneje Sue preveri svojo datoteko. Ta nova datoteka mora vsebovati njene spremembe in Bobove spremembe. To se doseže s postopkom združitve.

Odvisno od programske opreme za nadzor različic, ki jo uporabljate, lahko to združitev obravnavate na različne načine. V nekaterih primerih, na primer ko sta Bob in Sue delala na popolnoma različnih delih datoteke, je postopek spajanja zelo preprost. V primerih, ko sta Sue in Bob delala z enakimi vrsticami kode v datoteki, je postopek spajanja lahko bolj zapleten. V teh primerih bo morala Sue sprejeti odločitve, na primer, ali bo Bobova koda ali njena koda v novi različici datoteke.

Po končanem postopku spajanja poteka postopek predaje datoteke v repozitorij. Zapis datoteke v bistvu pomeni ustvarjanje nove različice v repozitoriju; v tem primeru različica 7 datoteke.

Primeri programske opreme za nadzor različic druge generacije vključujejo sistem za sočasne različice (CVS) in Subversion.

Tretja generacija

Tretja generacija se imenuje porazdeljeni sistem za nadzor različic (DVCS). Tako kot pri drugi generaciji tudi osrednji strežnik repozitorija vsebuje vse datoteke za projekt. Vendar razvijalci posameznih datotek iz skladišča ne preverijo. Namesto tega je odjavljen celoten projekt, ki razvijalcu omogoča, da dela na celotnem naboru datotek in ne samo na posameznih datotekah.

Druga (zelo velika) razlika med drugo in tretjo generacijo programske opreme za nadzor različic je povezana s tem, kako deluje postopek združevanja in sprejemanja. Kot smo že omenili, so koraki v drugi generaciji izvedba združitve in nato nova različica preda v repozitorij.

S programsko opremo za nadzor različic tretje generacije se datoteke preverijo in nato združijo.

Recimo recimo, da dva razvijalca preverita datoteko, ki temelji na tretji različici. Če en razvijalec preveri to datoteko, pri čemer nastane različica 4 datoteke, mora drugi razvijalec najprej združiti spremembe iz svoje odjavljene kopije s spremembami različice 4 (in morebiti druge različice). Po končani združitvi lahko novo različico shranite v repozitorij kot različico 5.

Če se osredotočite na tisto, kar je v skladišču (osrednji del vsake faze), vidite, da obstaja zelo ravna črta razvoja (ver1, ver2, ver3, ver4, ver5 itd.). Ta preprost pristop k razvoju programske opreme predstavlja nekaj potencialnih težav:

  • Zahteva, da se razvijalec združi, preden se zaveže, pogosto povzroči, da razvijalci ne želijo redno izvajati sprememb. Postopek spajanja je lahko težaven in razvijalci se lahko odločijo, da počakajo pozneje in naredijo eno združitev, ne pa več običajnih združitev. To negativno vpliva na razvoj programske opreme, saj se nenadoma v datoteko doda ogromno kosov kode. Poleg tega želite razvijalce spodbuditi, da v repozitorij vnesejo spremembe, tako kot nekoga, ki piše dokument, spodbudite k rednemu shranjevanju.
  • Zelo pomembno: Različica 5 v tem primeru ni nujno delo, ki ga je razvijalec prvotno zaključil. Med postopkom združevanja lahko razvijalec zavrže nekaj svojega dela, da dokonča postopek spajanja. To ni idealno, ker povzroči izgubo potencialno dobre kode.

Uporabimo lahko boljšo, čeprav verjetno bolj zapleteno tehniko. Se imenuje usmerjeni aciklični graf (DAG).

Predstavljajte si isti scenarij kot zgoraj, kjer dva razvijalca preverita različico 3 datoteke. Če en razvijalec to datoteko preveri, še vedno nastane različica 4 datoteke. Vendar drugi postopek prijave povzroči datoteko različice 5, ki ne temelji na različici 4, temveč je neodvisna od različice 4. V naslednji fazi postopka se različici 4 in 5 datoteke združita, da se ustvari različica 6.

Čeprav je ta postopek bolj zapleten (in potencialno veliko bolj zapleten, če imate veliko število razvijalcev), ponuja nekaj prednosti pred eno samo vrsto razvoja:

  • Razvijalci lahko svoje spremembe redno izvajajo in jim ni treba skrbeti za združitev do poznejšega časa.
  • Postopek združevanja bi lahko prenesel na določenega razvijalca, ki ima boljše predstave o celotnem projektu ali kodi kot drugi razvijalci.
  • Vodja projekta se lahko kadar koli vrne in natančno vidi, kakšno delo je ustvaril posamezni razvijalec.

Zagotovo obstaja argument za obe metodi. Vendar ne pozabite, da se ta članek osredotoča na Git, ki uporablja metodo usmerjenega acikličnega grafa sistemov za nadzor različic tretje generacije.

Namestitev Git

V sistemu morda že imate Git, ker je včasih privzeto nameščen (ali pa ga je morda namestil drug skrbnik). Če imate dostop do sistema kot običajni uporabnik, lahko z naslednjim ukazom ugotovite, ali imate nameščen Git:

ocs @ ubuntu: ~ $ kateri git / usr / bin / git

Če je nameščen Git, potem pot do datoteke git ukaz, kot je prikazano v prejšnjem ukazu. Če ni nameščen, potem ne dobite nobenega izhoda ali napake, kot je naslednja:

[ocs @ centos ~] # kateri git / usr / bin / kateri: nobenega gita ni (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/ bin: / usr / sbin: / bin: / sbin: / root / bin)

Kot skrbnik sistema, ki temelji na Debianu, lahko uporabljate dpkg ukaz za določitev, ali je bil nameščen paket Git:

root @ ubuntu: ~ # dpkg -l git Želeno = Neznano / Namesti / Odstrani / Odstrani / Zadrži | Status = Not / Inst / Conf-files / Unpacked / halF-conf / Half-inst / trig-aWait / ➥Trig-pend | / Err? = (None) / Reinst-required (Status, Err: uppercase = bad) | | / Ime Različica Arhitektura Opis +++ - ======== - ============= - ============= - === ===================================== ii git 1: 1.9.1-1ubun amd64 hitro, razširljivo , razdeljena ➥ revizija kon

Kot skrbnik sistema, ki temelji na Red Hat, lahko uporabljate vrtljajev na minuto ukaz za določitev, ali je bil git paket nameščen:

[root @ centos ~] # rpm -q git git-1.8.3.1-6.el7_2.1.x86_64

Če Git ni nameščen v vašem sistemu, se morate prijaviti kot korenski uporabnik ali uporabiti sudo ali su za namestitev programske opreme. Če ste prijavljeni kot korenski uporabnik v sistemu, ki temelji na Debianu, lahko za namestitev Gita uporabite naslednji ukaz:

apt-get install git

Če ste prijavljeni kot korenski uporabnik v sistemu, ki temelji na Red Hat, lahko za namestitev Gita uporabite naslednji ukaz:

yum namestite git

Pridobite več kot Git

Razmislite o namestitvi programskega paketa git-all. Ta paket vključuje nekaj dodatnih paketov odvisnosti, ki Gitu dodajo več moči. Čeprav teh funkcij morda ne boste uporabljali na začetku, bo dobro, če jih boste imeli na voljo, ko boste pripravljeni na izvajanje naprednejših funkcij Git.

Git koncepti in značilnosti

Eden od izzivov uporabe Gita je le razumevanje konceptov, ki stojijo za njim. Če konceptov ne razumete, so vsi ukazi videti kot nekakšna črna magija. Ta razdelek se osredotoča na kritične koncepte Git in vam predstavlja nekaj osnovnih ukazov.

Git faze

Zelo pomembno je, da si zapomnite, da preverite celoten projekt in da bo večina dela, ki ga opravite, potekalo lokalno glede na sistem, na katerem delate. Datoteke, ki jih preverite, bodo shranjene v imenik pod vašim domačim imenikom.

Če želite kopijo projekta dobiti iz repozitorija Git, uporabite postopek z imenom kloniranje. Kloniranje ne ustvari samo kopije vseh datotek iz skladišča; dejansko opravlja tri osnovne funkcije:

  • Ustvari lokalni repozitorij projekta pod Ime Projekta/.git v vašem domačem imeniku. Datoteke projekta na tem mestu veljajo za odjavljene iz centralnega repozitorija.
  • Ustvari imenik, kjer si lahko neposredno ogledate datoteke. To se imenuje delovno območje. Spremembe na delovnem območju niso takoj pod nadzorom različice.
  • Ustvari uprizoritveno območje. Predelovalno območje je namenjeno shranjevanju sprememb datotek, preden jih dodelite lokalnemu repozitoriju.

To pomeni, da če bi klonirali projekt z imenom Jacumba, bi bil celoten projekt shranjen v Jacumba / .git pod domačim imenikom. Ne smete jih poskušati neposredno spreminjati. Namesto tega poglejte neposredno v ~ / Jacumba imenik si oglejte datoteke iz projekta. To so datoteke, ki jih morate spremeniti.

Recimo, da ste datoteko spremenili, vendar morate delati na nekaterih drugih datotekah, preden ste bili pripravljeni za prevzem sprememb v lokalnem repozitoriju. V tem primeru bi stopnja datoteko, ki ste jo končali. To bi pripravilo, da bo zavezan lokalnemu repozitoriju.

Ko naredite vse spremembe in postavite vse datoteke, jih nato dodelite lokalnemu repozitoriju.

Zavedajte se, da predavanje stopenjskih datotek pošlje le v lokalno repozitorij. To pomeni, da imate dostop do sprememb, ki ste jih izvedli, samo vi. Postopek preverjanja novih različic v centralnem repozitoriju se imenuje a potisnite.

Izbira gostitelja shrambe Git

Prvič, dobra novica: Številne organizacije ponujajo gostovanje Git - v času pisanja tega besedila obstaja več kot dva ducata možnosti. To pomeni, da lahko izbirate med številnimi možnostmi. To so dobre novice ... in slabe novice.

To je le slaba novica, ker pomeni, da morate res nekaj časa raziskati prednosti in slabosti gostiteljskih organizacij. Na primer, večina ne zaračuna osnovnega gostovanja, plača pa velike projekte. Nekateri ponujajo samo javne repozitorije (vsak lahko vidi vaše repozitorij), drugi pa vam omogočajo, da ustvarite zasebne repozitorije. Upoštevati je treba še veliko drugih funkcij.

Ena izmed funkcij, ki je morda na vašem seznamu, je spletni vmesnik. Čeprav lahko skoraj vse operacije s skladiščem izvajate lokalno v sistemu, je lahko izvajanje nekaterih operacij prek spletnega vmesnika zelo koristno. Preden se odločite, raziščite vmesnik, ki je na voljo.

Vsaj priporočam, da upoštevate naslednje:

  • //bitbucket.org
  • //www.cloudforge.com
  • //www.codebasehq.com
  • //github.com
  • //gitlab.com

Upoštevajte, da sem za spodnje primere izbral Gitlab.com. Vsak gostitelj s prejšnjega seznama bi delal enako dobro; Za Gitlab.com sem se odločil preprosto zato, ker je slučajno bil tisti, ki sem ga uporabil pri zadnjem projektu Git.

Konfiguriranje Git

Zdaj, ko ste prestali vso teorijo, je čas, da nekaj dejansko naredite z Gitom. Ta naslednji odsek predvideva naslednje:

  • Namestili ste git ali git-all programski paket v vašem sistemu.
  • Ustvarili ste račun za storitev gostovanja Git.

Prva stvar, ki jo želite narediti, je nekaj osnovnih nastavitev. Kadar koli izvedete operacijo predaje, bosta vaše ime in e-poštni naslov vključena v metapodatke. Če želite nastaviti te podatke, izvedite naslednje ukaze:

ocs @ ubuntu: ~ $ git config --global user.name "Bo Rothwell" ocs @ ubuntu: ~ $ git config --global user.email "[email protected]"

Očitno boste zamenjali "Bo Rothwell" z vašim imenom in "[email protected]" s svojim e-poštnim naslovom. Naslednji korak je kloniranje vašega projekta iz storitve gostovanja Git. Upoštevajte, da je pred kloniranjem v uporabnikovem domačem imeniku le ena datoteka:

ocs @ ubuntu: ~ $ ls first.sh

Naslednji so klonirali projekt z imenom ocs:

$config[zx-auto] not found$config[zx-overlay] not found