9.1 Git in ostali sistemi - Git kot odjemalec

Osnovni ukaz v Gitu za vse ukaze povezane s Subversionom je git svn. Prikazali bomo najpogostejše ukaze, medtem ko se bomo sprehajali skozi nekaj preprostih potekov dela.

Pomembno je opozoriti, da pri uporabi git svn komunicirate s sistemom Subversion, ki deluje zelo drugače od Gita. Čeprav lahko izvajate lokalno razvejanje in združevanje, je običajno najbolje ohraniti zgodovino čim bolj linearno z uporabo ponovnega baziranja in izogibanjem stvarem, kot je hkratna interakcija z oddaljenim repozitorijem Git.

Ne spreminjajte svoje zgodovine in da poskusite znova potisniti, prav tako ne potiskajte v vzporedni repozitorij Git za sodelovanje s kolegi sodelavci Git hkrati. Subversion ima lahko samo eno linearno zgodovino in zamenjati jo je zelo enostavno. Če delate z ekipo, pri čemer nekateri uporabljajo SVN in drugi Git, poskrbite, da vsi uporabljajo strežnik SVN za sodelovanje — to vam bo olajšalo življenje.

Za prikaz te funkcionalnosti potrebujete tipični repozitorij SVN, ki ga lahko urejate. Če želite kopirati te primere, morate ustvariti zapisljivo kopijo testnega repozitorija SVN. Da to enostavno naredite, lahko uporabite orodje, ki ga dobite s Subversionom, imenovano svnsync.

Za nadaljevanje morate najprej ustvariti nov lokalni repozitorij Subversion:

Nato omogočite vsem uporabnikom, da spreminjajo revprops — enostaven način je dodati skript pre-revprop-change, ki vedno vrne izhodno kodo 0:

Sedaj lahko sinhronizirate ta projekt na vašo lokalno napravo s klicem svnsync init za v in iz repozitorijev.

To nastavi lastnosti za zagon sinhronizacije. Nato lahko klonirate kodo s pogonom:

Čeprav ta operacija lahko traja le nekaj minut, bo proces kopiranja prvotnega repozitorija na drug oddaljeni repozitorij namesto lokalnega trajal skoraj eno uro, kljub temu da je manj kot 100 potrditev. Subversion mora klonirati eno revizijo naenkrat in jo nato potisniti nazaj v drug repozitorij — to je nesmiselno neučinkovito, vendar je to edini enostaven način za izvedbo tega.

Zdaj, ko imate dostop za pisanje v repozitorij Subversion, lahko začnete s tipičnim potekom dela. Začnete z ukazom git svn clone, ki uvozi celoten repozitorij Subversion v lokalni repozitorij Git. Upoštevajte, da če uvažate iz resničnega gostujočega repozitorija Subversion, morate file:///tmp/test-svn nadomestiti z URL-jem vašega repozitorija Subversion:

To izvede ekvivalent dveh ukazov — git svn init in git svn fetch — na naslovu URL, ki ga podate. To lahko traja nekaj časa. Če ima na primer testni projekt približno samo 75 potrditev in koda ni tako velika, mora Git vseeno preveriti vsako različico eno za drugo in jo posamezno potrditi. Za projekt s stotine ali tisoče potrditev lahko to dejansko traja ure ali celo dni, da se dokonča.

Del -T trunk -b branches -t tags pove Gitu, da ta repozitorij Subversion sledi osnovnim konvencijam za razvejanje in označevanje. Če poimenujete svojo glavno vejo, veje ali oznake drugače, lahko spremenite te možnosti. Ker je to tako pogosto, lahko ta celoten del zamenjate s -s, kar pomeni standardni razpored in predpostavlja vse te možnosti. Naslednji ukaz je enakovreden:

V tem trenutku bi morali imeti veljaven repozitorij Git, ki je uvozil vaše veje in oznake:

Bodite pozorni, saj to orodje upravlja oznake Subversion kot oddaljene reference. Poglejmo podrobneje Gitov ukaz napeljave show-ref:

Git tega ne naredi, ko klonira iz strežnika Git; tako je videti repozitorij z oznakami po svežem kloniranju:

Git prinese oznake neposredno v refs/tags, namesto da jih obravnava kot oddaljene veje.

Zdaj, ko imate delovno mapo, lahko opravite nekaj dela na projektu in potisnete svoje spremembe nazaj navzgor in učinkovito uporabljate Git kot odjemalca SVN. Če uredite eno od datotek in jo potrdite, imate potrditev, ki obstaja v Gitu lokalno, vendar ne obstaja na strežniku Subversion:

Naslednji korak je, da svojo spremembo potisnete navzgor. Opazite, kako to spremeni način dela s Subversionom — lahko opravite več potrditev brez povezave in jih nato hkrati potisnete na strežnik Subversion. Za potiskanje na strežnik Subversion izvedete ukaz git svn dcommit:

To vzame vse potrditve, ki ste jih naredili na vrhu kode strežnika Subversion, za vsakega naredi potrditev Subversion in nato prepiše vašo lokalno potrditev Git tako, da vključi edinstven identifikator. To je pomembno, saj to pomeni, da se vse kontrolne vsote SHA-1 vaših potrditev spremenijo. Delno iz tega razloga ni dobra ideja, da bi hkrati delali z Gitovimi različicami vaših projektov na daljavo in strežnikom Subversion. Če si ogledate zadnjo potrditev, lahko vidite novi git-svn-id, ki je bil dodan:

Opazite, da se kontrolna vsota SHA-1, ki se je prvotno začela s 4af61fd, zdaj začne z 95e0222. Če želite potisniti na strežnik Git in strežnik Subversion, morate najprej potisniti (dcommit) na strežnik Subversion, saj ta dejanja spremenijo vaše podatke potrditve.

Če delate z drugimi razvijalci, se bo nekoč zgodilo, da bo eden od vas potisnil svoje spremembe, drugi pa bo poskušal potisniti spremembe, ki so v nasprotju s temi. Te spremembe bodo zavrnjene, dokler ne združite njihovega dela. V git svn je to videti tako:

Za rešitev te situacije lahko poženete git svn rebase, ki prenese spremembe na strežniku, ki jih še nimate, in ponovno bazira delo, ki ga imate na vrhu tega, kar je na strežniku:

Zdaj je vse vaše delo na vrhu tistega, kar je na strežniku Subversion, zato lahko uspešno izvedete dcommit:

Pomnite, da v primerjavi z Gitom, ki zahteva, da združite zgornje spremembe, ki jih še nimate lokalno, preden lahko potisnete, git svn to naredi le, če so spremembe konfliktne (podobno kot deluje Subversion). Če nekdo drug potisne spremembo v eno datoteko, nato pa vi potisnete spremembo v drugo datoteko, bo vaš dcommit deloval brez težav:

To si je pomembno zapomniti, saj je rezultat stanje projekta, ki ni obstajalo na nobenem od vaših računalnikov, ko ste ga objavili. Če spremembe niso združljive, vendar se prekrivajo brez konfliktov, lahko dobite težave, ki jih je težko diagnosticirati. To je drugače kot pri uporabi strežnika Git — v Gitu lahko stanje v celoti preizkusite na svojem odjemalcu pred objavo, medtem ko pri SVN-ju nikoli ne morete biti prepričani, da sta stanji takoj pred in po potrditvi enaki.

Prav tako morate pognati to ukazno vrstico, da pridobite spremembe s strežnika Subversion, tudi če še niste pripravljeni na potrditev. Za pridobitev novih podatkov lahko zaženete git svn fetch, vendar git svn rebase opravi pridobivanje in nato posodobi vaše lokalne potrditve.

Z občasnim zagonom ukaza git svn rebase zagotovite, da je vaša koda vedno posodobljena. Pri tem morate biti prepričani, da je vaš delovni direktorij čist, ko izvedete ta ukaz. Če imate lokalne spremembe, morate shraniti svoje delo, ali pa ga začasno potrditi, preden zaženete ukaz git svn rebase — sicer bo ukaz prekinjen, če ugotovi, da bo ponovno baziranje povzročilo konflikt med združevanjem.

Ko ste seznanjeni z Gitovim potekom dela, boste verjetno ustvarili tematske veje, delali na njih in jih nato združili. Če objavljate na strežniku Subversion prek git svn, boste morda želeli vsakič znova ponovno bazirati svoje delo na eno samo vejo, namesto da bi veje združevali skupaj. Razlog za prednost ponovnega baziranja je, da ima Subversion linearno zgodovino in se ne ukvarja z združevanjem, kot to počne Git, zato git svn sledi le prvi nadrejeni pri pretvarjanju posnetkov v potrditve Subversion.

Recimo, da je vaša zgodovina videti takole: ustvarili ste vejo experiment, naredili dve potrditvi in ju nato združili nazaj v master. Ko naredite dcommit, vidite izpis, kot je ta:

Poganjanje dcommit na veji z združeno zgodovino deluje, razen ko si ogledate zgodovino projekta v Gitu, saj ni preoblikoval nobene od sprememb, ki ste jih naredili na veji experiment — namesto tega se vsi ti podatki pojavijo v različici SVN posamezne potrditve združitve.

Ko to delo klonira nekdo drug, vidi le potrditev združitve s celotnim delom stisnjenim vanj, kot da ste izvedli git merge --squash; ne vidi se podatkov o potrditvi, od kod je prišla, ali kdaj je bila potrjena.

Veje v Subversionu niso enake kot v Gitu; če ga lahko čim manj uporabljate, je verjetno najbolje. Vendar pa lahko z uporabo git svn ustvarite veje v Subversionu in na njih potrjujete.

Da ustvarite novo vejo v Subversionu, lahko poženete git svn branch [new-branch]:

To naredi ekvivalent ukaza svn copy trunk branches/opera v Subversionu in deluje na strežniku Subversion. Pomembno je omeniti, da vas to ne izvleče v tisto vejo; če izvedete potrditev v tem trenutku, bo ta potrditev šla v trunk na strežniku, ne v vejo opera.

Git ugotovi, kam gredo vaši dcommiti, tako da išče vrh katerih koli vaših vej Subversion v vaši zgodovini — imeti morate samo eno, in to bi morala biti zadnja z git-svn-id v vaši trenutni veji.

Če želite delati na več kot eni veji hkrati, lahko nastavite lokalne veje, na katerih boste naredili dcommit v določene veje Subversion, tako da jih začnete pri uvoženi potrditvi Subversion za to vejo. Če želite vejo opera, na kateri lahko delate ločeno, lahko zaženete:

Če želite združiti vašo vejo opera v trunk (vaša veja master), lahko to storite z običajnim git merge. Vendar morate zagotoviti opisno sporočilo za potrditev (preko -m), sicer bo sporočilo o združevanju »Združi vejo opera« (angl. »Merge branch opera«) namesto nečesa uporabnega.

Pomnite, da čeprav za to operacijo uporabljate git merge in bo združevanje verjetno veliko lažje kot v Subversionu (ker bo Git samodejno zaznal ustrezno osnovo za združevanje), to ni običajna potrditev združevanja Git. Podatke morate potisniti nazaj na strežnik Subversion, ki ne more obdelati potrditve, ki sledi več kot eni nadrejeni; zato bo po potiskanju videti kot ena sama potrditev, ki je združila vsa dela druge veje pod eno potrditev. Po združevanju ene veje v drugo se ne morete enostavno vrniti in nadaljevati dela na tej veji, kot lahko običajno storite v Gitu. Ukaz dcommit, ki ga zaženete, izbriše vse informacije, ki pravijo, katera veja je bila združena, zato bodo naslednji izračuni osnovnih točk za združevanje napačni — dcommit naredi, da je vaš git merge videti, kot da ste zagnali git merge --squash. Na žalost ni dobrega načina za izogibanje tej situaciji — Subversion ne more shraniti teh informacij, zato boste vedno omejeni z njegovimi omejitvami, ko ga uporabljate kot vaš strežnik. Za izogibanje težavam morate po združitvi veje v trunk izbrisati lokalno vejo (v tem primeru opera).

Orodja git svn ponujajo nekaj ukazov, ki pomagajo olajšati prehod na Git s funkcionalnostjo, ki je podobna tisti, ki ste jo imeli v Subversionu. Tu je nekaj ukazov, ki vam dajo tisto, kar ste imeli v Subversionu.

Orodja git svn so uporabna, če ste ujeti s strežnikom Subversion ali pa ste v razvojnem okolju, ki zahteva zagon strežnika Subversion. Vendar ga morate šteti kot osiromašeni Git, saj se boste sicer soočili s težavami pri prevajanju, ki vas in vaše sodelavce lahko zmedejo. Da bi se izognili težavam, poskusite slediti tem smernicam:

Če sledite tem smernicam, bo delo s strežnikom Subversion bolj znosno. Vendar če je mogoče, preklop na pravi strežnik Git lahko vaši ekipi prinese veliko več.

Najprej morate namestiti git-remote-hg. To v bistvu vključuje odlaganje njegove datoteke nekam v vašo pot, takole:

… če je ~/bin v vaši $PATH. Git-remote-hg ima še eno odvisnost: knjižnico mercurial za Python. Če imate Python nameščen, je to zelo preprosto:

Če nimate nameščenega Pythona, obiščite https://www.python.org/ in ga najprej namestite.

Zadnja stvar, ki jo boste potrebovali, je odjemalec Mercurial. Če ga še niste namestili, obiščite https://www.mercurial-scm.org/ in ga namestite.

Zdaj ste pripravljeni za uporabo. Potrebujete samo repozitorij Mercurial, kamor lahko potiskate. Na srečo lahko vsak repozitorij Mercurial deluje na ta način, zato bomo uporabili repozitorij »hello world«, ki ga vsi uporabljajo za učenje Mercuriala:

Zdaj, ko imamo ustrezen repozitorij »strežniške strani«, lahko opravimo običajen potek dela. Kot boste videli, sta ta dva sistema dovolj podobna, da ni veliko trenja.

Kot vedno pri Gitu, najprej kloniramo:

Opazili boste, da delo z Mercurialovim repozitorijem uporablja standardni ukaz git clone. To je zato, ker git-remote-hg deluje na precej nizki ravni in uporablja podoben mehanizem, kot je implementacija Gitovega protokola HTTP/S (oddaljeni pomočniki). Ker sta Git in Mercurial zasnovana tako, da ima vsak odjemalec polno kopijo zgodovine repozitorija, ta ukaz naredi celotno kopijo, vključno z vso zgodovino projekta, in to relativno hitro.

Ukaz log prikaže dve spremembi, najnovejša od teh je označena z velikim številom referenc. Izkazalo se je, da nekatere od teh referenc dejansko ne obstajajo. Poglejmo, kaj je dejansko v direktoriju .git:

Git-remote-hg skuša stvari narediti bolj v slogu, ki je bolj podoben Gitu, toda v ozadju upravlja osnovno preslikavo med dvema nekoliko drugačnima sistemoma. Mapiranje med oddaljenimi referencami dejansko poteka v mapi refs/hg. Na primer, datoteka z referenco Git refs/hg/origin/branches/default vsebuje SHA-1, ki se začne z »ac7955c«, to pa je tista potrditev, na katero kaže master. Tako je mapa refs/hg nekako lažna različica refs/remotes/origin, vendar ima dodatno razlikovanje med zaznamki in vejami.

Datoteka notes/hg je izhodišče za preslikavo med Gitovimi zgoščenimi vrednostmi potrditev in ID-ji sprememb Mercuriala, ki jih uporablja git-remote-hg. Poglejmo si to nekoliko podrobneje:

Torej refs/notes/hg kaže na drevo, ki je v Gitovi objektni bazi podatkov seznam drugih objektov z imeni. git ls-tree izpiše način, vrsto, zgoščeno vrednost objekta in ime datoteke za elemente znotraj drevesa. Ko se potopimo v enega od elementov drevesa, odkrijemo, da je znotraj njega objekt z imenom ac9117f (zgoščena vrednost SHA-1 potrditve, na katero kaže master), z vsebino 0a04b98 (to je ID nabora sprememb Mercurial na vrhu veje default).

Dobra novica je, da se nam s tem večinoma ni treba ukvarjati. Tipičen potek dela ne bo preveč drugačen od dela z oddaljenim repozitorijem Git.

Preden nadaljujemo, moramo rešiti še eno stvar: ignoriranje datotek. Mercurial in Git uporabljata za to zelo podoben mehanizem, vendar verjetno ne želite dejansko shraniti datoteke .gitignore v repozitorij Mercurial. Na srečo ima Git način za ignoriranje datotek, ki je lokalno za posamezen diskovni repozitorij, in format Mercuriala je združljiv z Gitom, zato ga le prekopirajte:

Datoteka .git/info/exclude se obnaša enako kot .gitignore, vendar v potrditvah ni vključena.

Naj predpostavimo, da smo opravili nekaj dela in naredili nekaj potrditev na veji master ter ste pripravljeni, da jih pošljete na oddaljeni repozitorij. Tako je videti naš repozitorij trenutno:

Naša veja master je dva predhodnika pred origin/master, toda ti dve potrditvi obstajata le na našem lokalnem računalniku. Poglejmo, ali je kdo drug v istem času opravljal kakšno pomembno delo:

Ker smo uporabili zastavico --all, vidimo tudi reference »notes«, ki jih uporablja git-remote-hg, vendar jih lahko ignoriramo. Preostalo je tako, kot smo pričakovali; origin/master se je premaknil za eno potrditev in naša zgodovina se je zdaj razcepila. V primerjavi z drugimi sistemi, s katerimi delamo v tem poglavju, lahko Mercurial upravlja združevanja, zato ne bomo počeli ničesar zapletenega.

Odlično. Zaženemo teste in vse poteka brez napak, zato smo pripravljeni deliti svoje delo z ostalimi člani ekipe:

To je vse! Če si ogledamo repozitorij Mercurial, vidimo, da je ta ukaz storil, kar smo pričakovali:

Spremenitve z oznako 2 so bile narejene z Mercurialom, spremembe z oznakami 3 in 4 pa so bile narejene z git-remote-hg, s pomočjo potiskanja potrditev, narejenih z Gitom.

Git ima samo eno vrsto veje: referenco, ki se premika, ko so narejene potrditve. V Mercurialu se ta vrsta reference imenuje »zaznamek« (angl. bookmark) in se obnaša podobno kot Gitova veja.

Mercurialova zasnova »veje« je bolj obremenjujoča. Veja, na kateri je bil narejen nabor sprememb, je zabeležena z naborom sprememb, kar pomeni, da bo vedno v zgodovini repozitorija. Tu je primer za potrditev, ki je bila izvedena na veji develop:

Poglejte vrstico, ki se začne z »branch«. Git tega ne more dejansko ponoviti (in tudi ne potrebuje; oba tipa vej lahko predstavimo kot Git ref), vendar mora git-remote-hg razumeti razliko, saj Mercurial skrbi za to.

Ustvarjanje zaznamkov Mercurial je enostavno, kot ustvarjanje vej Git. Na strani Git:

To je vse, kar spada sem. Na strani Mercurial je videti takole:

Opazite novo oznako [featureA] v reviziji 5. Te se obnašajo enako kot veje Git na strani Git, do ene izjeme: iz Gitove strani ne morete izbrisati zaznamka (to je omejitev oddaljenih pomočnikov).

Prav tako lahko delate na »težkih« vejah Mercurial: preprosto postavite vejo v imenski prostor branches:

Takole bo videti stran Mercurial:

Ime veje »permanent« je bilo zabeleženo z označenim naborom sprememb 7.

S stališča Gita je delo z enim od teh načinov vej enako: preprosto izvlečete, potrdite, pridobite, združite, povlečete in potisnite, kot bi sicer storili. Ena stvar, ki jo morate vedeti, je, da Mercurial ne podpira ponovnega pisanja zgodovine, ampak samo dodajanje k njej. Tako je videti naš repozitorij Mercurial po interaktivnem ponovnem baziranju in prisilnem potiskanju:

Nabori sprememb 8, 9 in 10 so bili ustvarjeni in spadajo v vejo permanent, vendar so stari nabori sprememb še vedno tam. To lahko zelo zmede vaše sodelavce, ki uporabljajo Mercurial, zato se temu poskusite izogniti.

Git in Mercurial sta dovolj podobna, da je delo prek meje precej neboleče. Če se izogibate spreminjanju zgodovine, ki je že zapustila vaš računalnik (kar je običajno priporočljivo), morda sploh ne boste vedeli, da je drugi konec Mercurial.

Perforce ponuja izdelek, imenovan Git Fusion (dostopen na https://www.perforce.com/manuals/git-fusion), ki sinhronizira strežnik Perforce z repozitoriji Git na strežniški strani.

Git-p4 je most med Gitom in Perforceom v dveh smereh. Deluje v celoti znotraj vašega repozitorija Git, zato ne boste potrebovali nobene vrste dostopa do strežnika Perforce (razen seveda uporabniških poverilnic). Git-p4 ni tako prilagodljiva ali popolna rešitev tako kot Git Fusion, vendar vam omogoča, da večino tega, kar bi radi storili, izvedete brez poseganja v okolje strežnika.

Git-p4 omogoča uporabo poteka dela Git s strežnikom Perforce in je pri tem zelo učinkovit. Vendar pa je pomembno vedeti, da je Perforce odgovoren za vir in da uporabljate Git le lokalno. Bodite previdni pri deljenju potrditev Git; če imate oddaljeni repozitorij, ki ga uporabljajo druge osebe, ne potiskajte nobenih potrditev, ki še niso bile predložene na strežnik Perforce.

Če želite prosto mešati uporabo Perforce in Git kot odjemalcev za nadzor izvorne kode, in če lahko prepričate upravitelja strežnika, da ga namesti, lahko uporabite Git Fusion, ki omogoča uporabo Git kot odjemalca za strežnik Perforce.