7.11 Orodja Git - Podmoduli

Najenostavnejši model uporabe podmodulov v projektu bi bil, če bi enostavno uporabljali podprojekt in občasno želeli dobiti njegove posodobitve, vendar ga dejansko ne bi nikakor spreminjali pri vašem izvleku. Pojdimo tu skozi enostaven primer.

Če želite preveriti novo delo v podmodulu, lahko greste v direktorij in poženete git fetch in git merge, da posodobite vejo povratnega toka in posodobite svojo lokalno kodo.

Če greste sedaj nazaj v svoj glavni projekt in poženete git diff --submodule, lahko vidite, da je bil podmodul posodobljen in dobite seznam vseh potrditev, ki so mu bile dodane. Če ne želite vsakič vpisovati --submodule, ko poženete git diff, lahko možnost nastavite kot privzeti format z nastavitvijo konfiguracijske vrednosti diff.submodule na »log«.

Če v tem trenutku potrdite, boste podmodul zaklenili, da ima novo kodo, ko bodo drugi posodabljali.

Da to naredite, obstaja enostavnejša pot, če imate raje ročno prenašanje in združevanje v poddirektoriju. Če poženete git submodule update --remote, bo šel Git v vaše podmodule in vam jih prenesel ter posodobil.

Ta ukaz bo privzeto predvideval, da želite posodobiti izvlek na privzeto vejo oddaljenega podmodula (tistega, na katerega kaže HEAD na oddaljenem mestu). Vendar če želite, lahko to nastavite na nekaj drugega. Na primer, če želite, da podmodul DbConnector sledi veji »stable« tega repozitorija, lahko to nastavite v datoteki .gitmodules (tako, da jo spremljajo tudi drugi), ali pa v lokalni datoteki .git/config. Nastavimo jo v datoteki .gitmodules:

Če izpustite -f .gitmodules, bo naredil samo spremembo za vas, vendar je morda bolj smotrno, da sledite tej informaciji z repozitorijem, da lahko to naredi tudi vsakdo drug.

Ko v tem trenutku poženemo git status, nam bo Git pokazal, da imamo v podmodulu »nove potrditve«.

Če nastavite konfiguracijsko nastavitev status.submodulesummary, vam bo Git tudi pokazal kratek povzetek sprememb na vaših podmodulih:

Če v tem trenutku poženete git diff, lahko vidimo, da imamo spremenjeno tako našo datoteko .gitmodules kot tudi, da je veliko potrditev, ki smo jih povlekli, in so pripravljene za potrditev v našem projektu podmodula.

To je kar odlično, saj lahko dejansko vidimo dnevnik potrditev, ki jih bomo ravno potrdili v našem podmodulu. Ko je enkrat potrjeno, lahko vidimo te informacije tudi po tem, kot tudi, ko poženete git log -p.

Ko poženete git submodule update --remote, bo Git privzeto poskusil posodobiti vse vaše podmodule. Če jih imate veliko, boste morda želeli podati tudi ime samo tistega podmodula, ki ga želite posodobiti.

Postavimo se sedaj v vašega sodelavca, ki ima svoj lokalni klon repozitorija MainProject. Enostaven pogon git pull, da dobite svoje nove potrjene spremembe, ni dovolj:

Privzeto ukaz git pull rekurzivno pridobi spremembe v podmodulih, kar lahko vidimo v izpisu prvega zgoraj navedenega ukaza. Vendar ne posodobi podmodulov. To kaže izpis ukaza git status, ki prikazuje, da je podmodul »spremenjen« in ima »nove potrditve«. Poleg tega oklepaji, ki kažejo nove potrditve, kažejo levo (<), kar kaže, da so te potrditve zabeležene v glavnem projektu, vendar niso prisotne v lokalnem izvleku DbConnector. Da dokončate posodobitev, morate zagnati git submodule update:

Bodite pozorni, da ste na varni strani, saj bi morali zagnati ukaz git submodule update z zastavico --init, če ste pravkar pridobili spremembe v glavnem projektu, ki so dodale nove podmodule, in z zastavico --recursive, če imajo podmoduli vdelane podmodule.

Če želite ta postopek avtomatizirati, lahko ukazu git pull dodate zastavico --recurse-submodules (od Git 2.14 dalje). To bo Gitu omogočilo, da takoj po potegu zažene ukaz git submodule update in podmodule postavi v pravilno stanje. Če želite vedno uporabljati --recurse-submodules za git pull, lahko nastavite konfiguracijsko možnost submodule.recurse na true (to deluje za git pull od verzije Git 2.15 dalje). Ta možnost bo Gitu omogočila, da uporabi zastavico --recurse-submodules za vse ukaze, ki to podpirajo (razen clone).

Obstaja posebna situacija, ki se lahko zgodi med posodabljanjem nadrejenega projekta: lahko se zgodi, da je oddaljeni repozitorij spremenil URL podmodula v datoteki .gitmodules v eni od potrditev, ki ste jo povlekli. To se lahko zgodi, na primer, če se projekt podmodula spremeni na drugo gostiteljsko platformo. V takem primeru lahko git pull --recurse-submodules ali git submodule update spodleti, če se nadrejeni projekt sklicuje na potrditev podmodula, ki je ni mogoče najti v oddaljenem podmodulu, ki je lokalno konfiguriran v vašem repozitoriju. Da bi rešili to situacijo, je potreben ukaz git submodule sync:

Verjetno uporabljate podmodule, ker resnično želite delati na kodi v podmodulu istočasno, ko delate na glavni kodi (ali med več podmoduli). Drugače bi verjetno namesto tega uporabljali preprostejši sistem upravljanja odvisnosti (kot sta Maven ali Rubygems).

Pojdimo skozi primer spreminjanja podmodula istočasno z glavnim projektom ter hkratnega potrjevanja in objavljanja teh sprememb.

Do sedaj, ko smo zagnali ukaz git submodule update, da dobimo spremembe iz podmodulov, Git dobi spremembe in posodobi datoteke v poddirektoriju, vendar pusti podrepozitorij v »stanju ločene glave« (angl. detached HEAD state). To pomeni, da ni lokalne delovne veje (kot je na primer master), ki bi sledila spremembam. Če ni delovne veje, ki spremlja spremembe, to pomeni, da bodo spremembe, ki jih potrdite v podmodulu, verjetno izgubljene, ko naslednjič zaženete git submodule update. Za sledenje spremembam v podmodulu morate opraviti nekaj dodatnih korakov.

Da bi lažje začeli urejati podmodul, morate storiti dve stvari. Morate iti v vsak podmodul in izbrati vejo, na kateri boste delali. Nato morate Gitu povedati, kaj naj naredi, če ste naredili spremembe, in git submodule update --remote povleče nove spremembe od povratnega toka. Možnosti so, da jih lahko združite s svojim lokalnim delom, ali pa lahko poskusite postaviti svoje lokalno delo na vrh novih sprememb.

Najprej pojdimo v svoj imenik podmodula in si izvlecimo vejo.

Poskusimo posodobiti naš podmodul z možnostjo »združevanja«. Da ga ročno določimo, lahko enostavno dodamo možnost --merge našemu klicu update. Tu bomo videli, da je bila za ta podmodul sprememba na strežniku in da je združena.

Če gremo v direktorij DbConnector, imamo nove spremembe že združene v našo lokalno vejo stable. Sedaj poglejmo, kaj se zgodi, ko naredimo na knjižnici svoje lastne lokalne spremembe in nekdo drug istočasno potisne drugo spremembo na povratni tok.

Če sedaj posodobimo naše podmodule, lahko vidimo, kaj se zgodi, če imamo tako lokalno kot tudi zgornjo spremembo, ki jo moramo vdelati.

Če pozabite --rebase ali --merge, bo Git posodobil samo podmodul na karkoli je na strežniku in ponastavil vaš projekt na »stanje ločene glave« (angl. detached HEAD state).

Če se to zgodi, ne skrbite, enostavno lahko greste nazaj v direktorij in ponovno izvlečete svojo vejo (ki bo še vedno vsebovala vaše delo) ter ročno združite, ali ponovno bazirate glede na origin/stable (ali katero koli oddaljeno vejo želite).

Če niste potrdili vaših sprememb v vašem podmodulu in poženete submodule update, ki bi povzročil težave, bo Git prenesel spremembe, vendar ne bo prepisal neshranjenega dela v vašem direktoriju podmodula.

Če ste naredili spremembe, ki so v konfliktu z nečim iz povratnega toka, vas bo Git obvestil, da poženete posodobitev.

Lahko greste v direktorij podmodula in popravite konflikt, kot bi to običajno storili.

Sedaj imamo nekaj sprememb v našem direktoriju podmodula. Nekatere od teh so bile prinesene iz povratnega toka z našimi posodobitvami, ostale pa so bile narejene lokalno in niso še nikomur na voljo, saj jih še nismo potisnili.

Če naredimo potrditev v glavnem projektu in jo potisnemo navzgor, ne da bi hkrati potisnili tudi spremembe podmodulov, bodo imeli drugi ljudje, ki poskušajo prenesti naše spremembe, težave, saj ne bodo imeli načina, da dobijo spremembe podmodulov, od katerih so odvisni. Te spremembe bodo obstajale samo v naši lokalni kopiji.

Da se to ne zgodi, lahko Git zaprosite, da preveri, ali so bili vsi podmoduli pravilno potisnjeni, preden potisnete glavni projekt. Ukaz git push sprejme argument --recurse-submodules, ki ga lahko nastavimo na »check« ali »on-demand«. Možnost »check« bo naredila, da bo ukaz push preprosto spodletel, če niso bile potisnjene vse potrjene spremembe podmodulov.

Kot vidite, nam prav tako ponuja nekaj koristnih nasvetov o tem, kaj bi morda želeli storiti naslednje. Preprosta možnost je, da vstopite v vsak podmodul in ročno potisnete na oddaljene strežnike, da se prepričate, da so na voljo od zunaj, nato pa poskusite ta potisk znova. Če želite, da se ta »check« zgodi za vse potiske, lahko to obnašanje nastavite kot privzeto z ukazom git config push.recurseSubmodules check.

Druga možnost je uporaba vrednosti »on-demand«, ki bo to poskušala storiti namesto vas.

Kot vidite, je šel Git v modul DbConnector in ga potisnil, preden je potisnil glavni projekt. Če ta poskus potiska podmodula zaradi nekega razloga spodleti, bo spodletelo tudi potiskanje glavnega projekta. To obnašanje lahko nastavite kot privzeto z ukazom git config push.recurseSubmodules on-demand.

Če spremenite referenco podmodula istočasno kot nekdo drug, lahko naletite na nekaj težav. To je, če so se zgodovine podmodulov razšle in so bile potrjene v različnih vejah v nadrejenem projektu, bo morda potrebno nekaj dela, da jih popravite.

Če je ena od oddaj neposreden prednik druge (združitev fast-forward), bo Git preprosto izbral slednjo za združitev, zato to deluje brez težav.

Git vam vendarle ne bo poskušal narediti niti trivialnega združevanja. Če se potrditve podmodulov razlikujejo in jih je treba združiti, boste dobili nekaj takega:

Torej, kar se je tu zgodilo, je, da je Git ugotovil, da se točke v zgodovini podmodula v dveh vejah razhajajo in da jih je treba združiti. Pojasni, kot »združitve naslednjih potrditev niso bile najdene«, kar je zmedeno, vendar bomo to pojasnili malo kasneje.

Za rešitev problema morate ugotoviti, v katerem stanju naj bo podmodul. Presenetljivo Git ne ponuja veliko informacij, ki bi pomagale pri tem, niti SHA-1 potrditev obeh strani zgodovine. Na srečo je to preprosto ugotoviti. Če zaženete git diff, lahko dobite SHA-1 potrditve, posnete v obeh vejah, ki jih poskušate združiti.

Torej v tem primeru je potrditev eb41d76 v našem podmodulu in c771610 je potrditev, ki jo ima zgornji nivo. Če gremo v podmapo podmodula, bi ta že morala biti na eb41d76, saj združevanje ni vplivalo nanj. Če ni, lahko preprosto ustvarite in preklopite na vejo, da kaže nanj.

Pomembno je, da uporabimo SHA-1 potrditve na drugi strani. To je potrditev, ki jo bomo morali združiti in rešiti morebitne konflikte. Lahko poskusite neposredno združiti s SHA-1, ali pa ustvarite novo vejo in poskusite združiti z njo. Priporočljivo je slednje, tudi če samo zaradi boljše opisne sporočilnosti potrditve združitve.

Zato bomo šli v podmapo podmodula, ustvarili vejo z imenom »try-merge« na podlagi drugega SHA-1 zapisa iz git diff in jo ročno združili.

Tu dobimo dejansko konflikt pri združevanju, torej če ga rešimo in potrdimo, lahko potem enostavno posodobimo glavni projekt z rezultatom.

Morda je malo zmedeno, vendar ni zelo težko.

Zanimivo je, da Git obravnava še en primer. Če v podmapi obstaja potrditev združitve, ki vsebuje obe zgodovinski potrditvi, jih Git predlaga kot možno rešitev. Vidi, da je nekdo v podmapi projektov združil veji s tema dvema potrditvama, zato je morda to tisto, kar želite.

Zato je sporočilo o napaki od prej »združitve naslednjih potrditev niso bile najdene«, ker tega ni mogel storiti. Zmeda, saj kdo bi pričakoval, da bo poskusil narediti to?

Če najde eno samo potrditev združitve, ki je sprejemljiva, boste videli nekaj takega:

Predlagan ukaz, ki ga Git ponuja, bo posodobil indeks tako, kot bi to storili z ukazom git add (ki odpravlja konflikt), nato bo naredil potrditev. Verjetno tega ne bi smeli storiti. Prav tako lahko enostavno vstopite v imenik podmodula, preverite, kakšna je razlika, hitro previjete naprej (fast-forward) na to potrditev, jo ustrezno preizkusite in nato potrdite.

To doseže enako stvar, vendar tako vsaj lahko preverite, da deluje in da imate kodo v vašem direktoriju podmodula, ko končate.

Obstaja ukaz podmodulov foreach, ki izvede neki poljuben ukaz v vsakem podmodulu. To je lahko koristno, če imate veliko podmodulov v istem projektu.

Na primer, recimo, da želimo začeti novo lastnost ali popraviti hrošča, in imamo delo v teku na nekaj podmodulih. Enostavno lahko damo vso delo v vseh naših podmodulih v shrambo.

Nato lahko ustvarimo novo vejo in preklopimo nanjo v vseh naših podmodulih.

To je razumljivo. Ena izmed resnično uporabnih stvari, ki jo lahko naredite, je, da izdelate dobro poenoteno razliko tega, kar se je spremenilo v vašem glavnem projektu in tudi v vseh vaših podprojektih.

Tu lahko vidimo, da smo definirali funkcijo v podmodulu in jo kličemo v glavnem projektu. To je očitno poenostavljen primer, vendar upamo, da vam da idejo, kako je lahko to koristno.

Morda želite nastaviti nekatere bližnjice za nekatere od teh ukazov, saj so lahko precej dolgi in večine od njih ne morete nastaviti kot privzete možnosti konfiguracije. Nastavljanje bližnjic za Git smo že obravnavali v Aliasi Git, vendar vam tukaj predstavljamo primer, kaj lahko nastavite, če nameravate veliko delati s podmoduli v Gitu.

Na ta način lahko enostavno poženete git supdate, ko želite posodobiti vaše podmodule, ali git spush, da jih potisnete s preverjanjem odvisnosti podmodula.

Na primer, preklapljanje vej s podmoduli v njimi je lahko malo zapleteno z različicami Gita starejšimi od 2.13. Če ustvarite novo vejo, dodate tja podmodul in nato preklopite nazaj na vejo brez podmodula, boste še vedno imeli podmodul v direktoriju kot nesledeni direktorij:

Odstranjevanje direktorija ni težavno, vendar je lahko malo nerazumljivo imeti to tam. Če ga odstranite in nato preklopite nazaj na vejo, ki ima ta podmodul, boste morali pognati submodule update --init, da ga ponovno zapolnite.

Ponovno, ni resnično težavno, vendar je lahko malenkost nerazumljivo.

Novejše različice Git (Git >= 2.13) vse to poenostavijo z dodatkom zastavice --recurse-submodules pri ukazu git checkout, kar poskrbi za podajanje podmodulov v pravo stanje za vsako vejo, na katero preklapljate.

Uporaba zastavice --recurse-submodules ukaza git checkout lahko prav tako pride prav, ko delate na več vejah v nadrejenem projektu in ima vsaka vaš podmodul usmerjen na različne potrditve. Če torej preklopite med vejami, ki beležijo podmodul na različnih potrditvah, se bo ob izvajanju ukaza git status podmodul pojavil kot »spremenjen« (angl. modified) in bo označeval »nove potrditve« (angl. new commits). To je zato, ker privzeto stanje podmodula ni preneseno med preklopi vej.

To vas lahko zelo zmede, zato je vedno dobra ideja, da uporabite git checkout --recurse-submodules, kadar vaš projekt vsebuje podmodule. Za starejše različice Git, ki nimajo zastavice --recurse-submodules, lahko po izvleku uporabite git submodule update --init --recursive, da postavite podmodule v pravilno stanje.

Na srečo lahko Git (>=2.14) vedno uporablja zastavico --recurse-submodules, če nastavite konfiguracijsko možnost submodule.recurse: git config submodule.recurse true. Kot je omenjeno zgoraj, bo to povzročilo, da se bo Git ponovno pogreznil v podmodule za vsak ukaz, ki ima možnost --recurse-submodules (razen git clone).

Druga velika težava, s katero se srečuje veliko ljudi, se nanaša na prehajanje iz podimenikov v podmodule. Če ste spremljali datoteke v svojem projektu in jih želite premakniti v podmodul, morate biti previdni, saj vam Git ne bo naklonjen. Predpostavimo, da imate datoteke v podmapi svojega projekta in jih želite preklopiti v podmodul. Če izbrišete podmapo in nato zaženete submodule add, vam Git javi napako:

Direktorij CryptoLibrary morate najprej odstraniti iz področja priprave. Nato lahko dodate podmodul:

Recimo, da ste to storili v veji. Če poskušate preklopiti nazaj v vejo, kjer so te datoteke še vedno v dejanskem drevesu namesto v podmodulu, boste prejeli to napako:

Spremembo lahko prisilite s checkout -f, vendar bodite previdni, da v tej mapi nimate neshranjenih sprememb, saj bi jih lahko ta ukaz prepisal.

Nato, ko se vrnete nazaj, boste iz neznanega razloga dobili prazno mapo CryptoLibrary in tudi git submodule update morda ne bo pomagal. Morda boste morali iti v podmapo podmodula in zagnati git checkout ., da dobite vse datoteke nazaj. To lahko za več podmodulov zaženete v skriptu submodule foreach.

Pomembno je opozoriti, da podmoduli dandanes ohranjajo vse svoje podatke Git v direktoriju .git glavnega projekta, tako da v primerjavi z veliko starejšimi različicami Git izbris podmodula ne bo izgubil nobenih oddanih potrditev ali vej.

Z uporabo teh orodij lahko podmoduli predstavljajo precej preprost in učinkovit način za razvoj več povezanih, a še vedno ločenih projektov hkrati.