7.11 Гит алати - Подмодули

Најједноставнији модел коришћења подмодула у пројекту је када једноставно употребљавате потпројекат и желите да с времена на време преузмете његова ажурирања, али ништа не мењате у својој одјављеној верзији пројекта. Хајде да прођемо кроз једноставни пример.

Ако желите проверити има ли новог рада у подмодулу, можете да одете у директоријум и извршите git fetch и git merge узводне гране чиме ажурирате локални кôд.

Ако се сада вратите назад у главни пројекат и извршите git diff --submodule видећете да је подмодул ажуриран и исписаће вам се листа комитова који су му додати. Ако не желите да куцате --submodule сваки пут када извршавате git diff, то можете да подесите као подразумевани формат постављењем конфигурационе вредности diff.submodule на „log”.

Ако у овом тренутку комитујете, онда ћете подмодул закључати тако да садржи нови кôд онда када остали људи ажурирају.

Постоји такође и лакши начин да се ово уради, ако вам се не свиђа да поддиректоријум ручно преузмете и спојите. Ако извршите команду git submodule update --remote, програм Git ће прећи у ваш подмодуле и уместо вас урадити преузимање и ажурирање.

Ова команда ће подразумевано претпостављати да желите одјавити master грану подмодул репозиторијума. Међутим, ако желите, то можете поставити на нешто друго. На пример, ако желите да DbConnector подмодул прати „stable” грану тог репозиторијума, можете то да подесите или у свом .gitmodules фајлу (тако да је и сви остали прате), или само у свом локалном .git/config фајлу. Хајде да је поставимо у .gitmodules фајлу:

Ако изоставите -f .gitmodules измена ће важити само за вас, али вероватно има више смисла да се та информација прати у репозиторијуму, тако да сви остали то раде.

Када у овом тренутку извршимо git status, програм Гит ће нам приказати да имамо „new commits” (нове комитове) у подмодулу.

Ако подесите конфигурационо подешавање status.submodulesummary, програм Гит ће вам такође приказати и кратак резиме измена у вашим подмодулима:

Ако у овом тренутку извршимо git diff видећемо и да нам је измењен .gitmodules фајл и да такође постоји већи број комитова које смо повукли и који су спремни за комит у нашем подмодул пројекту.

Ово је заиста одлично јер можемо да видимо лог комитова које ћемо управо комитовати у наш подмодул. Након комитовања, ту информацију можете видети када извршите git log -p.

Када извршите git submodule update --remote, програм Гит ће подразумевано покушати да ажурира све ваше подмодуле. Ако их имате доста, вероватно ћете пожелети да проследите име оног подмодула за који желите да се покуша ажурирање.

Хајде да сада ускочимо у ципеле вашег сарадника који има сопствени локални клон репозиторијума MainProject. Просто извршавање git pull за преузимање свеже комитованих измена није довољно:

Команда git pull подразумевано рекурзивно преузима измене подмодула, као што видимо изнад у излазу прве команде. Међутим, она не ажурира подмодуле. Ово се види у излазу git status команде који приказује да је подмодул „modified” (измењен) и да има „new commits” (нове комитове). Уз то, заграде говоре да нови комитови показују улево (<), што значи да су ти комитови забележени у MainProject али нису присутни у локалном DbConnector одјављивању. Да бисте довршили ажурирање, морате да извршите git submodule update:

Да бисте били сигурни, приметите да би git submodule update требало да извршите са заставицом --init у случају да су нови MainProject комитови које сте управо повукли додали нове подмодуле и са --recursive заставицом за случај да неки од подмодула имају угњеждено подмодуле.

Ако овај процес желите да аутоматизујете, команди git pull (почевши од Гит верзије 2.14) можете да додате заставицу --recurse-submodules. Ово ће наложити програму Гит да изврши git submodule update непосредно након повлачења, постављајући подмодуле у исправно стање. Уз то, ако желите да програм Гит увек повлачи са --recurse-submodules, можете да поставите конфигурациону опцију submodule.recurse на true (ово функционише за git pull почевши од верзије 2.15 програма Гит). Ова опција ће навести програм Гит да заставицу --recurse-submodules употребљава за све команде које је подржавају (осим clone).

Постоји специјална ситуација која може да се догоди када се повлаче ажурирања суперпројекта: може се десити да је у једном од комитова које повлачите узводни репозиторијум променио URL адресу подмодула у .gitmodules фајлу. Ово може да се деси, на пример, ако This can happen for example if the submodule project changes its hosting platform. У том случају је могуће да git pull --recurse-submodules или git submodule update не успеју да се изврше ако суперпројекат указује на комит подмодула који не може да се нађе у удаљеном репозиторијуму подмодула локално конфигурисаном у вашем репозиторијуму. Да би се решила ова ситуација, потребна је команда git submodule sync:

Врло је вероватно да ако користите подмодуле, то чините јер заиста желите да радите на коду у подмодулу истовремено уз рад на коду главног пројекта (или преко неколико подмодула). У супротном бисте сигурно користили једноставнији систем за управљање зависностима (као што је Maven или Rubygems).

Па хајде да сада прођемо кроз пример прављења измена у подмодулу истовремено са изменама у главном пројекту и комитовање и објављивање тих измена у исто време.

До сада, кадгод смо извршавали команду git submodule update да преузмемо измене из репозиторијума подмодула, програм Гит би преузео измене и ажурирао фајлове у поддиректоријуму, али би под-репозиторијум оставио у такозваном „detached HEAD” (одвојен HEAD) стању. То значи да нема локалне радне гране (као што је master, на пример) која прати измене. Када нема радне гране која прати измене, чак и ако комитујете измене у подмодулу, оне ће највероватније изгубити када следећи пут извршите git submodule update. Морате урадите неке додатне кораке ако желите да се измене у подмодулу прате.

Ако подмодул желите подесити тако да буде лакше да само уђете у њега и почнете да дељете, морате урадити две ствари. Потребно је да уђете у сваки подмодул и одјавите грану у којој ћете радити. Затим програму Гит морате рећи шта да ради ако сте направили измене, а git submodule update --remote он да повуче нови рад са узводног репозиторијума. Имате две опције: можете да их спојите у свој локални рад, или можете покушати да ребазирате свој локални рад на врх нових измена.

Најпре, хајде да одемо у директоријум подмодула и одјавимо грану.

Покушајмо да „merge” опцијом ажурирамо наш подмодул. Ручно је наводимо тако што update позиву једноставно додамо опцију --merge. Овде ћемо видети да је на серверу дошло до промене за овај подмодул и она се спаја.

Ако пређемо у DbConnector директоријум, видећемо да су нове измене већ спојене у нашу локалну stable грану. Хајде сада да видимо шта се дешава када направимо локалну измену библиотеке па неко други у исти време гурне узводно другу промену.

Аса сада ажурирамо свој подмодул видећемо шта се дешава у случају када смо направили локалну измену, а постоји и узводна измена коју морамо да уведемо.

Ако заборавите да наведете --rebase или --merge, програм Гит ће једноставно ажурирати подмодул на оно што се налази на серверу и ресетоваће ваш пројекат на стање одвојен HEAD.

Ако се то догоди, не брините, једноставно се можете вратити назад у директоријум и поново одјавити своју грану (која још увек садржи ваш рад) и ручно спојити или ребазирати origin/stable (или коју год удаљену грану желите).

Ако своје измене подмодула још увек увек нисте комитовали, па покренете ажурирање подмодула, имаћете проблема, програм Гит ће преузети измене али неће преписати несачуван рад у вашем директоријуму подмодула.

Ако сте направили измене које су у конфликту са нечим што се променило узводно, програм Гит ће вас обавестити о томе када покренете ажурирање.

Можете отићи у директоријум подмодула и исправити конфликте, као што бисте и иначе урадили.

Сада имамо неке измене у нашем директоријуму подмодула. Неке од њих су дошле узводно кроз наше ажурирање, а остале су урађене локално и још увек никоме нису доступне јер их нисмо објавили.

Ако комитујемо у главном пројекту и гурнемо га узводно, а да не гурнемо и измене у подмодулу, остали људи који покушају да одјаве наше измене биће у проблему јер неће имати начина да дођу до измена подмодула од којих зависе. Те измене ће постојати само у нашој локалној копији.

Ако желите обезбедити да до овога не дође, можете затражити од програма Гит да провери да ли су сви важи подмодули исправно гурнути пре него што гурне главни пројекат. Команда git push узима --recurse-submodules аргумент који може да се постави било на „check” или на „on-demand”. Опција „check” ће учинити да push једноставно не успе са извршавањем ако било које од комитованих измена подмодула нису још увек гурнуте.

Као што видите, команда вам приказује и корисне савете у вези могућих наредних корака. Једноставна могућност је да пређете у сваки подмодул и да ручно гурнете на удаљене репозиторијуме и тако обезбедите да су доступни споља када поново покушате гурање главног пројекта Ако желите да се ово понашање провере дешава за сва гурања, поставите га да буде подразумевано са git config push.recurseSubmodules check.

Друга могућност је да се користи вредност „on-demand” која ће ово покушати да уради уместо вас.

Као што видите, програм Гит је прешао у DbConnector модул у гурнуо га пре него што је гурнуо главни пројекат. Ако из неког разлога ро гурање не успе, неће успети ни гурање главног пројекта. Ово понашање можете поставити као подразумевано извршавањем git config push.recurseSubmodules on-demand.

Ако измените референцу на подмодул у исто време кад и неко други, можете наићи на проблеме. То јест, ако су се историје подмодула разишле и комитоване у одвојене гране суперпројекта, биће потребно мало рада да то поправите.

Ако је један од комитова директни предак другог (спајање методом брзог премотавања унапред), онда ће програм Гит за спајање једноставно изабрати тај други и то лепо функционише.

Међутим, програм Гит уместо вас неће покушати чак ни тривијално спајање. Ако се комитови подмодула разилазе и потребно је да се споје, видећете нешто слично овоме:

Оно што се у суштини десило овде је да је програм Гит открио да све гране бележе тачке у историји подмодула које се разилазе и потребно је да се споје. Он то објашњава као „merge following commits not found” (није пронађено спајање након комитова), што донекле збуњује, па ћемо ускоро објаснити зашто је тако.

Да бисте решили проблем, потребно је да одредите стање у којем подмодул треба да се налази. Чудно, али програм Гит вам у овој ситуација не пружа доста информација које могу да вам помогну, чак ни SHA-1 суме комитова са обе стране историје. Не срећу, ово једноставно може да се одреди. Ако извршите git diff видећете SHA-1s суме комитова који су забележени у обе гране које покушавате да спојите.

Дакле, у овом случају је eb41d76 комит у нашем подмодулу који ми имамо, а c771610 је комит који долази узводно. Ако пређемо у директоријум подмодула, већ би требало да се налази на eb41d76 јер спајање није утицало на њега. Ако из било ког разлога није тако, једноставно можете да креирате и одјавите грану која показује на њега.

Важна је SHA-1 сума комита са друге стране. То је оно што треба да спојите и да разрешите. Можете просто да пробате спајање директно са SHA-1, или можете креирати грану за њега, па покушати њу да спојите. Ми предлажемо ово друго, ако ништа друго, да бисмо могли написати лепшу поруку за комит спајања.

Дакле, прећи ћемо у директоријум подмодула, направићемо грану базирану на том другом SHA-1 из излаза комаде git diff и ручно ћемо да је спојимо.

Овде је дошло до конфликта при спајању, тако да ако га разрешимо и комитујемо, онда једноставно можемо да ажурирамо главни пројекат тим резултатом.

Можда помало збуњује, али заиста није тешко.

Интересантно је да постоји још један случај који програм Гит сам обрађује. Ако у директоријуму подмодула постоји комит спајања који у својој историји садржи оба комита, програм Гит ће вам то предложити као могуће решење. Он види да је у неком тренутку подмодул пројекта неко спојио гране које садрже ова два комита, па је могуће да ћете пожелети тај.

Ово је разлог што се приказује порука „merge following commits not found”, јер није био у стању да уради ово. Забуну уноси питање да ли би било ко и очекивао да програм Гит ово покуша?

Ако пронађе макар један прихватљиви комит спајања, видећете нешто слично овоме:

Команда коју програм Гит предлаже ће ажурирати индекс исто као да сте извршили git add (што означава да је конфликт разрешен), па затим комитује. Мада то вероватно не би требало да урадите. Исто тако можете лако да одете у директоријум подмодула, погледате шта је разлика, брзо премотате унапред на овај комит, тестирате га како треба, па га онда комитујете.

Ово постиже исти резултат, али барем можете проверити да функционише и када завршите имате кôд у директоријуму свог подмодула.

Постоји foreach подмодул команда која служи за извршавање произвољне комаде у сваком од подмодула. Ово може доста да помогне ако у истом пројекту имате већи број подмодула.

На пример, рецимо да желимо почети рад на новој могућности или да исправимо баг, а рад се одвија у више подмодула. Лако можемо да сакријемо комплетан рад у свим нашим подмодулима.

Затим можемо да креирамо нову грану и пређемо на њу у свим нашим подмодулима.

Схватате поенту. Једна заиста корисна ствар коју можете да урадите је да направите лепу уједињену разлику онога што је промењено у главном пројекту, као и у свим потпројектима.

Овде можемо видети да дефинишемо функцију у подмодулу и позивамо је из главног пројекта. Ово је очигледно упрошћен пример, али надамо се да вам даје представу колико може бити корисно.

Вероватно ћете хтети да поставите неколико алијаса за неке од ових команди, јер могу бити прилично дугачке и за већину не можете поставити подразумеване опције конфигурацијом. Постављање алијаса у програму Гит смо објаснили у covered setting up Git aliases in Гит алијаси, али овде дајемо пример шта можете поставити ако планирате доста да радите са подмодулима у програму Гит.

На овај начин једноставно можете извршити git supdate кадгод желите да ажурирате своје подмодуле, или git spush да гурнете подмодул уз проверу зависности.

На пример, пребацивање са гране на грану која у себи има подмодуле може бити компликовано. Ако креирате нову грану, тамо додате подмодул, па се вратите назад на грану без подмодула, још увек ћете имати директоријум подмодула као непраћен директоријум:

Уклањање директоријума није тако тешко, али збуњује то што га уопште имате тамо. Ако га уклоните, па се онда вратите назад на грану која има тај подмодул, мораћете да извршите submodule update --init да бисте га поново попунили.

Да поновимо, није толико компликовано, али помало збуњује.

Новије верзије програма Гит (Git >= 2.13) све ово поједностављују додавањем заставице --recurse-submodules команди git checkout која брине о постављању подмодула у стање које одговара грани на коју прелазимо.

Употреба заставице --recurse-submodules команде git checkout такође може бити корисно када радите на неколико грана суперпројекта, а свака од њих има ваше подмодуле који показују на различите комитове. Заиста, ако пређете са гране на грану која не бележи подмодул на истом комиту, након извршавања команде git status подмодул ће се појавити као „modified” (измењен) и означаваће „new commits” (нови комитови). Разлог за ово је што се стање подмодула подразумевано не преноси приликом преласка на другу грану.

Ово заиста може уносити забуну, тако да је добра идеја да увек извршавате git checkout --recurse-submodules када ваш пројекат има подмодуле. У старијим верзијама програма Гит које немају заставицу --recurse-submodules, након одјављивања можете употребити git submodule update --init --recursive и тако поставите подмодуле у одговарајуће стање.

Срећом, програму Гит (>=2.14) можете конфигурационом опцијом submodule.recurse навести да увек корсити заставицу --recurse-submodules: git config submodule.recurse true. Као што је напоменуто изнад, то ће навести програм Гит да рекурзивно посети подмодуле за свку команду која у себи има наведену опцију --recurse-submodules (осим git clone).

Друго главно ограничење на које многи људи наиђу се тиче претварања поддиректоријума у подмодуле. Ако сте у свом пројекту пратили фајлове и желите да их померите у подмодул, морате бити опрезни иначе ће програм Гит да се наљути на вас. Претпоставимо да имате фајлове у поддиректоријуму свог пројекта и да желите да га претворите у подмодул. Ако обришете поддиректоријум па онда извршите submodule add, програм Гит вам каже следеће:

Директоријум CryptoLibrary најпре морате да уклоните са стејџа. Након тога можете да додате подмодул:

Претпоставимо сада да сте то урадили у грани. Ако покушате да се вратите на грану у којој су ти фајлови још увек у стаблу, а не у подмодулу, враћа вам се следеће грешка:

Можете принудно да пређете са checkout -f, али будите пажљиви да тамо немате несачуване измене јер би ова команда могла да их препише.

Затим, када се вратите назад, имате празан CryptoLibrary директоријум и можда га ни git submodule update не поправи. Потребно је да се вратите и директоријум подмодула и извршите git checkout . да вратите назад све своје фајлове. Ово бисте могли да извршите у submodule foreach скрипти ако имате више подмодула.

Важно је приметите да у данашње време подмодули чувају све своје Гит податке у .git директоријуму основног пројекта, за разлико од много старијих верзија програма Гит, уништавање директоријума подмодула нећете изгубити ниједан комит или грану коју сте имали.

Уз ове алате, подмодули могу да буду прилично једноставан и ефективан метод за истовремено развијање неколико повезаних, али ипак одвојених пројеката.